Key Challenges in Cloud Migration Projects

Cloud migration sits high on every modernization roadmap, but the gap between the slide deck and the actual cutover can be wide. The promised outcomes – lower infrastructure costs, easier scaling, faster releases – are real, but they don’t arrive automatically when you flip the switch on a new environment. They show up when teams plan for the hard parts and execute against them.

Across the migrations our teams have delivered – from migrating a histopathology lab system from Oracle to Google Cloud Platform and moving a sports betting platform between hyperscalers, to rearchitecting financial services platforms for growth, a consistent set of challenges keeps surfacing. Read on to explore six of them and see how our teams overcame them.

Untangling legacy database dependencies

The database is almost always the hardest part of any migration, and legacy commercial databases are a category of their own. Years of stored procedures, custom triggers, vendor-specific SQL dialects and tightly coupled applications create a web of dependencies that can’t be lifted and shifted without breaking something downstream.

Migrating a laboratory diagnostics system from Oracle to GCP – at a time when this kind of move was still rare in Europe – meant working through every one of those dependencies before any data was moved. The lesson is that a database migration is rarely just a database project. Without thoroughly checking how every application around it actually uses the data, followed by deliberate sequencing so that nothing critical breaks during the cutover, it is challenging to build a holistic understanding of all data models and structures.

What works: Start with a full dependency map before you pick a target database. Decide early on whether you’re doing a like-for-like move (e.g., Oracle to a managed Oracle instance in the cloud) or a deeper change (e.g., Oracle to PostgreSQL). The right answer depends on how much technical debt you’re willing to carry forward versus refactor now.

Deciding what to refactor and what to leave alone

There’s a temptation in any migration to either change everything or change nothing. Both extremes get expensive. A pure lift-and-shift gives you a cloud bill instead of a data center bill but none of the architectural benefits. A full rewrite increases timelines and risks.

For our histopathology project, we handled this by moving the database to GCP first, then modernizing the surrounding system (backend, infrastructure, deployment model) in a sequence that let value land in stages. The legacy monolith was eventually transformed into containerized microservices with full CI/CD automation, but not all at once and not before the migration was stable.

What works: Apply the standard “6 Rs” framework (rehost, replatform, refactor, repurchase, retire, retain) workload by workload. Not every system deserves a refactor. Some deserve to be turned off entirely. Be ruthless about that conversation early.

Maintaining business continuity during cutover

For some systems, downtime translates directly into lost revenue or operational paralysis. This is especially true for diagnostic labs, payment platforms, betting markets, production lines and customer-facing financial services, where the cutover window is the moment everything is on the line. Zero-downtime deployments aren’t a nice-to-have. They’re the deliverable.

This is where careful planning of data synchronization, traffic routing and rollback paths makes the difference. The histopathology migration we worked on achieved zero-downtime deployments and was structured so our client could see performance improvements without an immediate dependency on a future PostgreSQL move. That kind of optionality only comes from sequencing the work so if something goes wrong, parts can be reversed independently.

What works: Plan the cutover as its own project. Build a tested rollback path before the first piece of production traffic moves and run a representative load against the new environment before, not during the switch.

Controlling cloud costs after the move

Though the “pay-as-you-go” model is one of the strongest arguments for the cloud, it’s also one of the easiest ways to overspend. Without active cost engineering, billing alerts and monitoring, organizations frequently end up paying more in the cloud than they did on-premises, then wonder where the promised savings went.

Real cost reduction comes from sustained work: right-sizing instances, using spot or reserved capacity where workloads allow, separating production from non-production environments and turning off resources that aren’t being used. On a recent sports betting platform transformation, deliberate optimization of the staging environment reduced costs by 70%, with 45% reduction on shared resources. Those numbers weren’t a side effect of migrating – they were the result of treating cost as an engineering metric.

What works: Set up a FinOps practice from day one. Tag every resource, make a single person or team accountable for the cloud bill and review it monthly the same way you review uptime.

Closing the observability gap

On-premises systems often have monitoring that’s been layered on for years. Though imperfect, they are familiar. After a migration, that institutional knowledge doesn’t carry over. Teams suddenly have new metrics, new tools, new failure modes and frequently less visibility than they had before (until they catch up).

Observability has to be in scope from the start. Logs, metrics and traces need to be aggregated, dashboards need to reflect what the team actually cares about and alerting needs to be tuned so the on-call rotation isn’t drowning in noise. When migrating a sports betting platform, increasing observability was an explicit goal alongside the move itself – and that’s the right way to frame it.

What works: Treat observability as a first-class workload in the migration plan, with its own design, owners and acceptance criteria. If you can’t see what’s happening in the new environment as clearly as in the old one, the migration isn’t done.

Transferring knowledge and enabling the team

When a cloud partner walks away, can an in-house team actually operate what’s been built? This is the question that decides whether a migration is a one-time project or the start of an ongoing maintenance issue. Documentation that’s written at the end, as an afterthought, rarely answers it. Writing documentation may not be the most enjoyable work, but in migration projects, it is necessary to make sure everything goes as planned.

The histopathology project explicitly built in comprehensive documentation and training so our client’s team could reach full operational independence. By doing this, we prevented the new platform from becoming the next legacy system, dependent on knowledge brought in by the cloud partner.

What works: Pair internal engineers with the migration team from day one and make documentation and runbooks part of the definition of done for each milestone. Additionally, run game-day exercises before go-live so the operations team has practiced the failure modes.

What ties it all together

Looking back across these challenges, none of them are technical problems in isolation. They’re decisions about scope, sequencing, ownership and what success actually means. The migrations that go well are the ones where these decisions are made deliberately, early, and with honest input from the people who’ll have to live with the result.

Cloud migration isn’t a single move. It’s a series of smaller moves, each of which can be done well or done poorly. The teams that recognize that and plan accordingly are the ones who get the outcomes the slide deck promised.

Thinking about a cloud migration and want to pressure-test your plan? Get in touch with our team of experts.

FAQ

What is the hardest part of a cloud migration?

The database. That’s because years of stored procedures, custom triggers, vendor-specific SQL dialects and tightly coupled applications create dependencies that can’t be lifted and shifted without breaking something.

What is the 6 R’s framework?

The 6 Rs framework stands for rehost, replatform, refactor, repurchase, retire, retain. It is a commonly used strategy in cloud computing when deciding how to migrate and modernize applications. Companies turn to the 6 R’s framework as it is designed to optimize costs and performance.

How to control cloud costs?

It’s important to pursue active cost engineering and implement billing alerts and monitoring mechanisms. Additionally, right-sizing instances, using spot or reserved capacity where workloads allow, separating production from non-production environments and turning off resources that aren’t being used all contribute to lower cloud costs.

How long does a cloud migration project take?

It depends on scope, but the honest answer is: longer than most organizations initially plan for. A simple lift-and-shift can be done in a few months. A migration involving database modernization, re-architecting a monolith into microservices, and team retraining is typically a multi-quarter effort. The biggest timeline killer isn’t the technical work itself but the discovery phase — mapping dependencies, deciding what to refactor versus rehost, and aligning stakeholders. Teams that invest properly upfront tend to finish faster overall.

What are the biggest risks of cloud migration?

The three that cause the most damage are unplanned downtime during cutover, runaway costs after the move and loss of operational knowledge once the migration team leaves. Downtime can be designed out through zero-downtime deployment patterns and tested rollback paths. Cost overruns are managed by treating FinOps as an engineering discipline from day one. Knowledge loss is the most underestimated risk. The way to overcome this is to pair internal engineers with the migration team throughout the project, not at handover.

Is cloud migration worth the investment?

For most organizations operating legacy systems, yes. But the value rarely comes from the migration itself. It comes from what becomes possible afterward: faster releases, automated deployments, easier scaling and the ability to integrate modern capabilities like AI without rebuilding the platform first. A lift-and-shift will save modest amounts on infrastructure but won’t change how the business operates. A migration paired with architectural modernization leads to gains that justify the effort.