How a Creekside Infrastructure Lead Found Her Next Career Chapter During a Cloud Migration

Cloud migrations are never just technical projects. They reshape teams, rewrite job descriptions, and often create career paths that didn't exist a year before. One Creekside infrastructure lead we'll call Maya found herself at exactly this crossroads when her company decided to move its core workloads from on-premises data centers to AWS. Maya had spent eight years managing physical servers, SAN storage, and VMware clusters. She knew her infrastructure inside out, but the cloud was a different beast. Instead of resisting the change, she used the migration as a catalyst to step into a cloud architecture role—and her story offers a blueprint for anyone facing a similar transition.

Why This Topic Matters Now

Workload migrations are happening at an unprecedented scale. According to industry surveys, over 60% of enterprises have active cloud migration initiatives, and the demand for experienced infrastructure professionals who can bridge the gap between legacy systems and modern cloud platforms is soaring. Yet many senior IT staff worry that their on-premises skills will become obsolete. The fear is understandable: if you've spent years mastering physical hardware, virtualization, and network topology, the shift to abstracted, API-driven infrastructure can feel like starting over.

But here's the reality that Maya discovered: deep infrastructure knowledge is exactly what cloud teams need. Understanding how data flows through a network, how storage subsystems behave under load, and how to troubleshoot latency at the hardware level gives you a perspective that pure cloud-native engineers often lack. The trick is to map your existing expertise onto cloud concepts and then fill the gaps deliberately.

This guide is for infrastructure leads, senior sysadmins, and operations managers who are facing a major cloud migration and want to come out the other side with a stronger career trajectory. We'll walk through Maya's journey, extract the principles that worked for her, and give you a framework to apply in your own context.

Core Idea in Plain Language

The central insight from Maya's experience is that a cloud migration is not a threat to your career—it's a career upgrade opportunity, but only if you treat it as such. The mistake many infrastructure professionals make is to try to protect their old role or to passively wait for someone to assign them new responsibilities. Instead, Maya actively looked for ways to inject herself into the migration planning and execution, even before the official project kicked off.

She started by attending every architecture review meeting she could find, even when they weren't directly related to her current team. She asked questions about networking design, security groups, and instance types—areas where her on-premises knowledge gave her an edge. She also volunteered to document the existing environment, a task that most people avoided, but which gave her a comprehensive view of what was moving and why.

The key principle here is that career growth during a migration comes from expanding your scope rather than deepening your specialization in legacy technology. Maya didn't stop being an infrastructure lead; she became an infrastructure lead who also understood cloud architecture. That dual identity is highly valuable because it reduces the risk of the migration and makes you indispensable to the new operational model.

Another part of the core idea is that you don't need to become a cloud expert overnight. Maya spent about three months studying for the AWS Solutions Architect Associate certification, but she didn't wait until she passed the exam to start contributing. She used her existing knowledge of capacity planning, disaster recovery, and security compliance to ask smart questions that the cloud-native architects hadn't considered. That earned her a seat at the table.

How It Works Under the Hood

Let's break down the mechanics of Maya's career transition into a repeatable process. It's not magic—it's a combination of situational awareness, skill mapping, and deliberate networking.

Step 1: Audit Your Current Role for Cloud-Relevant Skills

Maya made a list of everything she did daily: managing VMware clusters, troubleshooting storage performance, patching servers, handling backup and restore, managing firewall rules, and coordinating with network engineers. Then she mapped each task to a cloud equivalent. For example, VMware cluster management maps to EC2 Auto Scaling groups and placement groups. Storage performance troubleshooting maps to EBS volume types and provisioned IOPS. Backup and restore maps to AWS Backup and S3 lifecycle policies. This exercise gave her a vocabulary to speak the cloud language without starting from zero.

Step 2: Find the Migration Gaps

Every migration has gaps—areas where the planning is incomplete or where the cloud architects don't have deep knowledge of the existing environment. Maya looked for those. She noticed that the migration plan had no detailed network dependency mapping, so she offered to create one. She saw that the disaster recovery strategy was vague, so she wrote a comparison of on-premises DR vs. cloud DR options. These contributions were visible to leadership and directly tied to the migration's success.

Step 3: Build Relationships with the Cloud Team

Maya didn't stay in her silo. She started having coffee chats with the cloud architects, asking them about their biggest challenges and sharing her own insights. She learned that they were struggling with understanding the performance characteristics of the legacy database workloads, so she offered to run load tests and share the results. That collaboration turned into a formal partnership, and eventually she was invited to join the cloud architecture team full-time.

Step 4: Get Certified, But Don't Wait

Certifications are useful for credibility, but Maya's experience shows that hands-on contribution matters more. She studied for the AWS Solutions Architect Associate exam in her spare time, but she was already contributing to architecture decisions before she passed. The certification validated her knowledge, but the real career move happened because she demonstrated value during the migration itself.

Worked Example or Walkthrough

Let's walk through a concrete scenario based on Maya's experience, but with a different technology stack to illustrate the general pattern. Imagine you're a senior infrastructure lead at a mid-sized financial services company that runs its core trading platform on a mix of physical servers and Hyper-V VMs. The company has decided to migrate to Azure. Here's how you can apply Maya's approach.

Phase 1: Pre-Migration Audit (Weeks 1-4)

Start by documenting the current environment in detail. Create a spreadsheet with every server, its role, its dependencies, its performance baselines, and its backup schedule. This is grunt work, but it gives you a comprehensive view that nobody else has. While you're doing this, map each server to an Azure equivalent: Hyper-V VMs become Azure VMs, physical servers become bare-metal instances or are migrated to VMs, and so on. Note any special requirements like GPU acceleration or low-latency networking.

Phase 2: Identify Quick Wins (Weeks 5-8)

Look for workloads that are easy to migrate and have clear cloud benefits. For example, development and test environments that don't need high availability can be moved first to Azure Dev/Test subscriptions. Volunteer to lead these migrations. They're low-risk but give you hands-on experience with Azure Resource Manager, virtual networks, and cost management. Document the process and share it with the team.

Phase 3: Tackle the Hard Problems (Weeks 9-16)

Now focus on the most complex workloads—the ones that keep the cloud architects up at night. In Maya's case, it was a legacy database with strict latency requirements. She worked with the database team to test different Azure SQL Managed Instance configurations and eventually recommended a combination of read replicas and in-memory caching. This solution became the reference architecture for similar workloads. By solving a hard problem, she positioned herself as the go-to person for migration challenges.

Phase 4: Transition to Operations (Weeks 17+)

Once the migration is underway, the company will need someone to lead the new cloud operations team. Maya had already demonstrated her ability to manage both legacy and cloud environments, so she was the natural choice. She helped define the new incident response procedures, cost monitoring dashboards, and automation scripts. Her role evolved from infrastructure lead to cloud operations lead, with a significant increase in responsibility and visibility.

Edge Cases and Exceptions

Maya's story is not universal. There are situations where a migration might not create the same opportunities, and it's important to recognize them so you can adjust your strategy.

When the Migration Is Outsourced

If your company hires a third-party integrator to handle the entire migration, your internal role may shrink rather than grow. In that case, you need to position yourself as the internal liaison—the person who understands both the business context and the technical details. Offer to be the point of contact for the integrator, review their designs, and manage the transition of knowledge back to the internal team. That role can still lead to a cloud-focused position once the integrator leaves.

When the Cloud Team Is Already Full

Some companies already have a well-staffed cloud team and don't see a need to bring in infrastructure leads. In that scenario, focus on building bridges between the legacy team and the cloud team. You can become the migration champion who helps the cloud team understand the existing environment and helps the legacy team prepare for the change. That cross-functional role is often valued and can lead to a permanent hybrid role.

When Your Skills Are Deeply Niche

If your expertise is in a technology that has no direct cloud equivalent—like mainframe systems or specialized hardware—the path is harder but not impossible. You may need to invest in significant retraining, but your knowledge of business processes and data flows is still valuable. Look for cloud services that can emulate your niche environment, such as AWS Mainframe Modernization or Azure's mainframe migration tools, and become the expert in that bridge technology.

When Company Culture Resists Change

Some organizations treat cloud migration as a cost-cutting exercise and don't invest in retraining existing staff. In that case, your best move may be to build your cloud skills on your own time and then look for a new role at a company that values your combined experience. Maya's approach works best in environments where leadership is open to internal mobility, but it's still worth trying even in less supportive cultures—you might be surprised.

Limits of the Approach

The strategy of using a migration as a career springboard has real limitations. It's not a guaranteed path to promotion, and it requires significant extra effort on top of your day job. Maya spent evenings and weekends studying, attending meetings, and building relationships. That's not sustainable for everyone, especially if you have family commitments or health constraints.

Another limitation is that the approach depends on the migration timeline. If the migration is fast-paced and chaotic, you may not have time to position yourself strategically. In that case, focus on survival first—keep the lights on—and look for opportunities in the post-migration stabilization phase. That's when companies often realize they need experienced people to manage the new environment.

There's also the risk that you become too tied to the migration project and then find yourself without a clear role once it's complete. To avoid that, make sure you're building skills that are transferable to other cloud projects, not just the specific migration tasks. Learn the cloud provider's core services, automation tools, and monitoring frameworks so you can work on any cloud initiative.

Finally, this approach assumes that your manager and leadership are supportive of internal career growth. If they're not, you may need to look outside the company. Maya was lucky to have a manager who encouraged her to explore cloud roles, but not everyone does. In that case, the skills you build during the migration are still valuable for your resume, even if you need to change employers to realize the career benefit.

Reader FAQ

Do I need to get certified before I start contributing to the migration?

No. Maya contributed before she had any cloud certification. Certification helps with credibility, but hands-on contribution and domain knowledge are more important in the early stages. Start by learning the basics through free resources like AWS Skill Builder or Microsoft Learn, and then volunteer for small tasks.

What if my company is migrating to a cloud provider I don't know?

The principles are the same regardless of the provider. Focus on understanding the cloud concepts—compute, storage, networking, security—and then learn the specific services of your provider. Most cloud providers have free tiers and documentation that let you practice.

How do I find time to study while managing the migration?

Prioritize. You don't need to study everything at once. Pick one area that's directly relevant to the current migration phase—like networking or storage—and learn that deeply. Use small chunks of time, like 30 minutes a day, and focus on practical labs rather than theoretical reading.

What if I'm not an infrastructure lead but a junior team member?

The same approach works, but you may need to be more proactive. Volunteer for tasks that give you visibility, like documentation or testing. Find a mentor on the cloud team and ask for guidance. Your advantage is that you have less legacy knowledge to unlearn.

How do I handle resistance from colleagues who see the cloud as a threat?

Lead by example. Show that cloud skills complement existing expertise rather than replace it. Offer to help others learn, and share your successes. If the culture is toxic, focus on your own growth and consider moving to a more supportive team or company.

Practical Takeaways

Maya's story isn't just about one person's career—it's a template for anyone facing a cloud migration. Here's what you can do starting tomorrow:

• Audit your current skills and map them to cloud equivalents. Write down three on-premises tasks you do regularly and find the cloud service that replaces them.
• Find one migration gap that you can fill. It could be a missing dependency map, a performance test, or a security review. Volunteer to own it.
• Build one relationship with someone on the cloud team. Schedule a 15-minute chat and ask about their biggest challenge. Offer your help.
• Start a cloud certification path, but don't wait to finish it before contributing. Use the learning to inform your work, not the other way around.
• Document everything you do during the migration. This becomes your portfolio when you apply for cloud roles, either internally or externally.

The next time your organization announces a cloud migration, don't see it as a threat. See it as your next career chapter—and start writing it today.