Moving workloads and tooling without a weekend outage, including the migrations nobody writes a guide for because no official importer exists.
Migrations fail when they are treated as lift-and-shift. Moving virtual machines to EC2 is not cloud-native, it is the same estate with a different invoice, and the team that inherits it has all the old problems plus a new bill.
The harder part is rarely the technology. On a source control migration the technology is a day; working out who owns each repository, from commit history and old Slack threads, is the month. I plan for that part explicitly, because it is the part that decides whether the cutover happens on the date you told people.
ICF is early, so there are no named client logos here yet. What there is: public code you can open and read, and work described without naming whose it was.
01
Inventory
What exists, who owns it, and what is already dead. The last category is usually larger than anyone expects and it is free to move nothing.
02
Dry run
The whole migration against a copy, timed, so the cutover window is a measurement rather than an estimate.
03
Staged cutover
In groups, with both systems live during the overlap and the rollback available at every step.
04
Decommission
The old system switched off deliberately, on a date, after the reconciliation report is clean.
A data centre contract ends and nobody has run the numbers
The official importer does not cover your case
Nobody can say who owns half the repositories
A previous migration stalled and left you running both systems
Tell me what you are running and what is slowing you down. I reply within one business day, and I will say so if this is not work I should take.
Taking a small number of contracts