Most lift-and-shift migrations look successful on Sunday night and start unraveling by Wednesday morning. The workload is running, DNS has flipped, the status page is green. Then a service account nobody remembers starts failing, a contractor logs in with permissions they shouldn't have, and the on-call engineer discovers that identity provider federation was rarely quite finished. The cutover held. The 72 hours after it gave way.
For a compact tour of the specific mistakes that turn a clean cutover into a rescue engagement, Bit Rebels listed the cloud migration missteps to avoid, and the failure patterns show up in almost every post-mortem worth reading. The decisions below are the ones that decide whether your migration joins that list.
Decide Whether Identity Moves With the Workload or Ahead of It
The default instinct is to migrate identity alongside the workload. It feels tidy: one cutover, one weekend, one rollback plan. In practice, identity has to be right before the first user logs in, and treating it as a co-traveler is how teams end up with production traffic hitting a directory that hasn't finished syncing.
Moving identity ahead of the workload is slower and less satisfying. You stand up the new identity provider, federate it, run both environments in parallel, and prove that the same person gets the same access in both places before anything else moves. It costs a sprint. It also removes a common cutover-weekend fire.
The trade-off is real. Parallel identity means paying for two systems for a while and reconciling drift between them. Bundled identity means one bill and one weekend, with a much higher chance that the weekend runs into Tuesday. Pick deliberately, and write down which one you picked.
Choose Between Copying Permissions and Rebuilding Them
Lift-and-shift tooling will happily copy your existing permission model into the new environment. It will also copy every stale grant, every service account nobody owns, and every break-glass role that stopped being break-glass three years ago. The new environment inherits the old environment's sins, plus whatever fresh ones you introduce in week one.
Rebuilding permissions from a least-privilege baseline is the honest option. It's also the one most teams skip, because it turns a two-week project into a two-month one and forces a conversation with every department about what their people actually need. The payoff is a permission model you can defend in an audit.
A middle path exists. Copy permissions to get the workload running, then run access analyzers against the new environment on day one and revoke anything that hasn't been used in the first two weeks. It's a compromise, not a strategy, but it beats pretending the copy was clean.
Decide What Counts as an Identity Before Cutover
The word "identity" gets used loosely, and that looseness is where most post-cutover incidents live. A federal cloud identity playbook from GSA and the CIO Council draws the line clearly: human users, non-person entities, and the credentials that represent them all get governed, or none of them do.
Before you move anything, name every category and decide who owns it:
- Human employees. Federated through the identity provider, MFA enforced, deprovisioning tied to HR.
- Contractors and vendors. Time-boxed access, separate group, quarterly review that actually happens.
- Service accounts. Each one has a named human owner. If it doesn't, it gets disabled before cutover, not after.
- Machine identities. Workload identity federation where the platform supports it, short-lived credentials everywhere else.
- Break-glass accounts. Two of them, stored offline, alerted on every use.
A category without an owner by the Friday before cutover means the cutover isn't ready, and that rule is what keeps the 72-hour window from becoming a six-month cleanup.
Pick Your Blast Radius Before the First Bill
Lift-and-shift assumes the new environment looks like the old one, so teams tend to land everything in a single account or subscription. It's faster. It's also why the first invoice is unreadable and the first incident touches everything.
AWS's Migration Lens guidance on the Mobilize phase is direct about this: separate accounts per environment, least privilege from the first workload, and identity controls in place before the first server moves. The choice isn't whether to segment. It's whether to segment before cutover, when it costs a week, or after an incident, when it costs a quarter.
Write a Plan, Not a Runbook
A runbook tells you which button to press on Saturday night. A plan tells you what you're moving, why, who owns each piece afterward, what the rollback criteria are, and what the environment is supposed to look like a month later. Most lift-and-shift projects have the first document and skip the second.
The plan is where you decide, on paper, that identity moves first, that permissions get rebuilt rather than copied, that every non-person account has an owner, and that the environment is segmented before the first workload lands. Those decisions are cheap on Monday. They get expensive by the Tuesday after cutover, when a service account nobody remembers is holding a production role nobody assigned it.