I did my first migration in 2007. I've done a lot since. The technology changed each time. What made a migration succeed or fail did not.
The migrations, briefly
- 2007 – Sensata Technologies. Oracle Apps 11.5.10.2 with iRecruitment on Linux DMZ. Existing setup was Solaris.
- 2009 – News International. Oracle databases from Solaris to SUSE Linux. Data Guard for DR.
- 2014 – DNB Bank. Oracle to Exadata. Cards application from AIX 5.3 to 6.1, Oracle 10g to 12c.
- 2015 – Länsförsäkringar Bank. Bank applications across two Tieto DCs to HCL DC.
- 2019 – Adecco. 500+ Oracle, EBS, and PeopleSoft databases across DCs.
- 2020–2024 – Rogers Bank → RCI. Seven business-critical applications to AWS using Terraform and serverless.
- 2020–2024 – ExxonMobil. VM migration via AWS Migration Factory.
- 2022 – BORAL. Oracle from RDS to EC2. Yes, that direction.
What stayed constant
The 20% that is invisible dominates outcomes. In every migration, the runbooks, the inventory reconciliation, the DR strategy, the change advisory board submissions — the boring pre-work — is what determined whether the actual cutover went well. This has not changed in 20 years.
The customer's internal team either owns it or fails it. Migrations that succeeded had strong customer-side ownership of the target state. Migrations that failed had a customer who thought hiring us was the ownership. Consulting can bring capability, but not ownership.
The application always did something you didn't know about. Every single time. A batch job on the 15th of the month. A hardcoded IP. An unsigned certificate the security tool ignored. A scheduled task nobody remembered. Assume this. Discover them before cutover, not during.
The rollback plan has to be tested, not just written. Written rollback plans give false confidence. Tested rollback plans give real confidence. The difference is knowing whether your rollback takes 20 minutes or 2 hours.
Communication out to end users is undervalued. Every migration I've been part of had a spectrum of end-user experience. The best had end users who knew exactly what was happening, when, and what to do if X. The worst had end users who found out something changed when their morning report was broken. The technology was the same; the comms were not.
What did change
The tooling got dramatically better. In 2007 you migrated by hand-writing shell scripts and hoping. AWS Migration Factory in 2022 was doing in a click what took a team a week in 2010. This is real progress.
The pace expectation got faster. A 2010 migration timeline of 18 months is unimaginable to a 2024 customer. This is partly justified (tooling is faster) and partly wrong (the organizational change management is not).
Auditability got harder. Modern regulated migrations require evidence trails at a level that 2010 customers would have considered paranoid. This is largely good — audit-forcing discipline is real discipline.
The failure mode shifted. In 2010, migrations failed on capacity assumptions or storage assumptions. In 2024, they fail on IAM assumptions and networking assumptions. The complexity moved from the physical layer to the identity layer.
The Adecco lesson
The Adecco engagement was the one where I most understood how migrations really work. Five hundred databases sounds like it must be about databases. It is not. It is about:
- Getting an accurate list of five hundred databases (the CMDB said 480; we found 512).
- Sorting them into waves that respect application boundaries.
- Building a runbook that a team of ten can execute in parallel.
- Deciding which of the 500 will survive as-is, which will consolidate, which will retire.
- Sequencing cutovers so the applications' downstream systems don't break.
- Handing over to a support team that wasn't in the migration project.
The database work — Oracle to Oracle, or Oracle to EBS, or Oracle to PeopleSoft — was the least of it. Every technically hard part had a known solution. The hard parts were the boring parts.
The Rogers → RCI lesson
Different flavour of hard. Seven business-critical apps, hundreds of AWS accounts to configure, Terraform as the source of truth, serverless where possible. What I learned:
- Terraform is not IaC unless it's the source of truth. Half-Terraformed accounts drift and lie. Fully Terraformed accounts are debuggable.
- Serverless is faster to build and harder to operate. Every Lambda replaces a boring server with a novel operational surface. Novel operational surfaces are more expensive to run than boring servers.
- CI/CD for migration deploys is essential. Manual
terraform applyat 2am at scale is how mistakes compound. GitHub Actions or CodePipeline or CircleCI — some automated pipeline gating the apply — is not optional.
What I'd tell a 25-year-old me
The 22-year-old me thought migrations were about the technology. Twenty years in, they're about people and process, with technology as the enabler. The good migrations succeeded because we were good at all three. The bad ones failed because we were good at technology and mediocre at the other two.
Learn the technology. Deeply. But do not confuse it for the thing you're actually delivering. What you're delivering is a working target-state system with a customer team that can operate it. Everything else is means.
The next twenty years
I am in year 21 now, doing Agentic AI on AWS. The technology is genuinely different — probabilistic, stateful, harder to test, easier to demo. The things that make it succeed or fail are exactly what always made migrations succeed or fail. Ownership, pre-work, communication, tested rollback, respect for the boring bits.
Whatever comes after Agentic AI will look completely different. And the same rules will apply.