I’ve sat in that meeting more times than I can count. Leadership wants to “move to the cloud.” It comes with urgency, a deadline, maybe a budget line, but almost never a real definition of what success looks like. Somewhere between the kickoff deck and the go-live date, “migrate to the cloud” stops being a project and starts being treated as the strategy itself.
I learned how dangerous that is on a migration of more than 820 million records across a legacy financial data environment. It didn’t fail. But it came closer to failing than it should have, and the reason wasn’t the technology. It was that, for a while, we treated “migrate” as a verb instead of an outcome. Here’s what changed, and what I’d tell anyone about to sign off on a similar project.
Moving Data Isn’t the Same as Migrating It Correctly
When a migration gets framed as “get the data from System A to System B,” teams optimize for the wrong thing: speed. Pipelines move records fast, row counts match, everyone declares victory and moves on. In financial services or healthcare, that’s how you end up with a mess six months later: broken referential integrity, quietly corrupted fields, reconciliation gaps nobody notices until an auditor or a customer does.
At the scale we were working with, 820 million-plus records across legacy systems that had been patched, re-patched, and patched again over a decade, there wasn’t even a single agreed-upon definition of “correct.” Different downstream systems had each quietly built their own interpretation of the same fields over the years. Ignore that, and your migration might succeed in a demo and still fail at scale.
What Actually Turned It Around
A few things changed the outcome, and none of them were exotic.
We treated validation as a real deliverable, not something bolted on at the end. Before we moved a single record, we built automated checks comparing source and target against actual business rules, not just row counts or checksums. That caught problems while they were still cheap to fix, instead of after they’d already shipped into production.
We also flipped the usual order of operations. Most teams migrate the easy data first to show quick progress. We did the opposite: the messiest, highest-risk data sets went first, while the team still had the most attention and the freshest rollback options. By the time we got to the easy stuff, we’d already worked through the hard edge cases and knew exactly what to expect.
And every phase had a real rollback path, tested in advance, not just a forward plan. We barely used it. But just knowing it existed changed how people made decisions when things got tense. Teams without a way back tend to push through warning signs they should have stopped at.
The Conversation Nobody Wants to Have Early
None of that matters much if the business side and the architecture team are quietly solving different problems. Executives sponsoring a migration are usually thinking about a deadline and a budget line. The architecture team is thinking about data integrity and whether the lights stay on. Nobody says this out loud, but it shows up as pressure to skip a validation step “just this once” to hit a date, and that’s exactly the pressure that turns a small, manageable risk into an actual incident.
The fix isn’t a better status deck. It’s agreeing, early and explicitly, on what “done” actually means, not just that data moved, but that it’s been checked against real business rules, that there’s a documented path for fixing discrepancies, and that rollback is possible if something surfaces after cutover. Get executives to sign off on that definition before the project starts, and you remove most of the pressure that makes teams cut corners later.
How It Turned Out
We moved more than 820 million records without a single outage caused by bad data. Just as important, it lowered audit risk going forward: the validation work we built for the migration didn’t get shelved once the migration ended. It became the basis for ongoing data quality monitoring, and honestly, that part has probably paid off more than the migration itself.
It’s tempting, once the last record lands and the dashboards turn green, to call it done and move the team onto the next thing. Don’t. The validation rules, the reconciliation logic, the rollback tooling: that’s some of the most useful stuff a team builds during a migration, and it’s a waste to let it go stale the moment the project closes out.
What I’d Tell Any Leader Signing Off on One of These
If you’re the executive sponsoring a cloud migration, don’t ask your team “when will the data be moved.” Ask “how will we know it’s correct, and what happens if it isn’t.” If nobody can answer that clearly before the project starts, you don’t have a migration strategy yet, you have a moving plan with extra steps.
The cloud isn’t the strategy. It’s just the destination. The strategy is whatever discipline you bring to get there without quietly swapping a short-term deadline for a long-term liability. In our case, that was validation-first design, phasing by risk instead of convenience, and always leaving a way back. That’s the difference between a migration that holds up under an audit two years later and one that just looked finished on a status report.
About the Author
Arun Mishra is an Enterprise Architect and Senior Manager with 16 years of experience in financial services and healthcare technology, spanning event-driven architecture, real-time payments systems, cloud-native platform design, and ML-based fraud detection. He holds 8 AWS certifications, Google Cloud Professional Architect, and Google Generative AI Leader credentials. Connect with him on LinkedIn.
