Six weeks before the production cutover, the migration lead pulled up a dashboard nobody wanted to look at. The new platform ran on AWS. Half the engineering team had spent their careers in an on-prem data center. Two of the four ops staff had never touched a cloud console outside a weekend tutorial. The deployment pipeline was built on tools the team had read about but never operated. Everyone agreed the architecture was sound. Nobody could say with confidence that the people running it would know what to do when something broke at 2 a.m. on launch night.
This is the gap that go-live plans tend to skip. Budgets cover the platform, the migration partner, the security review, and the cutover weekend. The line item for getting the team ready to operate the thing rarely gets the same scrutiny. When it does appear, it usually shows up as a stack of generic vendor courses booked three months out, and everyone assumes that handles it.
It does not handle it.
You don't have a cloud skills gap, you have an operating gap on your stack
The first mistake is treating the problem as a general knowledge shortage. Leaders see a team that does not know "cloud" and reach for a broad curriculum that covers everything from networking fundamentals to serverless patterns. The team sits through forty hours of content, passes the quizzes, and still freezes the first time a load balancer health check fails in their actual environment.
General cloud literacy and operating readiness are different things. A certification path teaches you what a VPC is. It does not teach you how your VPC is segmented, which security groups your team owns, or what happens to traffic when your specific failover region goes down. The knowledge that matters on launch night is narrow and concrete. It lives at the intersection of the platform you bought, the architecture your team designed, and the runbooks that do not exist yet.
So the question to ask is not "does the team know cloud." It is "can this person run this task in this environment when something is on fire." That reframing changes what you build.
What breaks when training stays generic
Picture the alternative that most organizations default to. The team gets enrolled in a vendor certification track. AWS Solutions Architect, or the Azure equivalent. The content is good. It is also built for a hypothetical learner, not for your migration.
Three things break.
The content covers services you will never use and skips the three you depend on. A certification track gives equal weight to fifty services. Your stack uses eight of them heavily. The learner spends most of their study time on material that will not appear in their job, and the eight services they actually need get a single chapter each.
The practice happens in a sandbox that looks nothing like production. Vendor labs run in clean, empty accounts with default settings. Your environment has custom IAM policies, inherited tagging conventions, a peering setup someone configured two years ago, and a deployment process wired to your CI tooling. The skills do not transfer because the context does not match.
And the timing is wrong. Certifications take months and reward breadth. A go-live needs depth on a short clock. By the time someone earns the credential, the cutover has already happened, and the learning that would have mattered most arrived too late to use.
None of this means certifications are worthless. It means they answer a different question than the one a go-live asks.
Building the journey backward from the cutover
The fix starts with the runbook, not the course catalog. Before you pick any training, write down what your team will actually have to do in the first 90 days of operating the new platform. Deploy a release. Roll one back. Respond to a region failure. Restore from backup. Triage a spike in latency. Rotate a credential. Each of those is a concrete task tied to your environment.
That list becomes the curriculum. For every task, you ask one question: who on the team can do this today, unsupervised, in our environment, and who cannot. The answer is rarely a clean yes or no. It is usually "knows the concept, has never done it here," which is exactly the gap that generic training misses and targeted practice closes.
Then you build the learning to match. Short, scenario-based sessions run in a clone of the real environment, not a vendor sandbox. The people who designed the architecture teach the parts they built. The migration partner walks through the failure modes they have seen on similar cutovers. Each session ends with the learner executing the task themselves, in a staging account that mirrors production, while someone watches and corrects. You are not measuring completion. You are measuring whether the person can run the runbook.
This costs more upfront than buying seats in a course. Someone has to write the runbooks, build the staging clone, and pull senior engineers off delivery work to teach. That is the tradeoff, and it is a real one.
The tradeoffs are about time and who pays for it
The generic path is cheap to set up and expensive to recover from. You spend a few hundred dollars per seat, the team checks the training box, and you carry the risk into go-live. If the launch goes smoothly, you saved money. If it does not, you pay for the gap in incident response time, in the senior engineer who has to fix everything personally because nobody else can, and in the confidence the business loses watching the team scramble.
The targeted path is expensive to set up and cheap to recover from. You spend senior engineering hours building runbooks and labs in the weeks before launch, which is exactly when those engineers are busiest. The team goes into go-live having already done the hard tasks once, in a safe environment. The first real incident is a repeat, not a first encounter.
There is a third option that looks attractive and usually backfires. Hire cloud expertise and skip the training entirely. Bring in contractors who know the platform, let them run the launch, and figure out the upskilling later. This works until the contractors leave and take the operating knowledge with them. The team that has to own the platform for the next five years learned nothing during the one window where learning would have been cheapest, because the people who knew the answers were doing the work instead of teaching it.
What to do six weeks out
Start with the runbook list this week. Sit the migration lead and two senior engineers in a room and write down every operational task the team will face in the first 90 days. Aim for fifteen to twenty concrete tasks. Do not skip the ones that feel obvious.
Next, map each task to named people and mark the gaps honestly. Resist the urge to assume someone "probably knows it." If they have not done it in your environment, it is a gap.
Then build short, hands-on sessions for the top gaps only. Pick the five or six tasks that are both high-stakes and weakly covered, and ignore the rest for now. Each session runs in a staging clone and ends with the learner doing the task, watched, until they can do it clean.
Buy certifications later, after go-live, if you want broad depth for the long run. They are a fine investment for a team that already operates the platform. They are the wrong tool for closing a gap on a six-week clock.
The team six weeks from launch does not need to know everything about cloud. It needs to know how to run your platform when it misbehaves. Build the training around that, and the dashboard nobody wanted to look at starts showing names next to tasks instead of question marks.