Lessons from migrating a modern analytics platform
Platform migrations are never just technical. Notes on what goes right, what goes wrong, and what I'd do differently.
If you’ve been through a data platform migration, you know the pattern: the technical work is the part you can plan for. Everything else — the organizational friction, the stakeholder anxiety, the long tail of undocumented dependencies — is what actually determines whether it succeeds.
The honest timeline
Every migration takes longer than planned. This isn’t a failure of estimation — it’s a feature of the problem. You don’t know what you don’t know about the existing system until you start pulling it apart. Legacy SQL with implicit business logic, undocumented views that turn out to be critical, ETL jobs that nobody owns but everyone depends on.
The best thing you can do is build slack into the timeline and communicate honestly about what you’re discovering along the way.
Dual-running is expensive but necessary
Running old and new systems in parallel is painful. It doubles infrastructure costs, creates confusion about which system is the source of truth, and drains the team’s energy. But the alternative — a hard cutover with no fallback — is almost always worse.
The key is setting clear criteria for when the old system gets turned off, and being disciplined about actually meeting those criteria rather than letting dual-running become permanent.
What I’d do differently
Start with the stakeholders, not the technology. The technical migration is tractable — it’s fundamentally about moving SQL, reconfiguring pipelines, and validating outputs. The hard part is getting people to trust the new system, change their workflows, and let go of the old one.
If I were doing it again, I’d invest more time up front in understanding how people actually use the existing platform — not just what tables they query, but what decisions they make with the data and what their tolerance for disruption looks like.