Patterns for cloud migration

During migration assessments, common patterns often emerge, especially for large organizations. Based on my experience in large-scale assessments, I’d like to share the most common migration patterns.

The cloud migration is a key step in digital transformation for businesses.
It lays the foundation for offering modern digital services and gaining a competitive edge. Many older applications were built using different technologies for different departments, making migration complex. During migration assessments, common patterns often emerge, especially for large organizations.
Based on my experience in large-scale assessments, I’d like to share the most common migration patterns.

Big bang

During application rationalization, some small apps don’t need detailed planning for migration. These low-risk, non-critical apps can be moved using a “Big Bang” approach — all at once. They’re quick wins that show the value of migration planning.
Usually, these apps need only minor changes, like updates to pipelines or monitoring, and don’t require rollback plans.

Strangler

This is one of the safest and most common patterns for migrating large, complex legacy systems. It involves refactoring the architecture to make it modern, scalable, and modular. Migration happens in phases, carefully handling dependencies while running old and new systems together. Both environments work side by side using load balancers and routing rules. DevOps pipelines play a key role in managing this smooth transition. This approach is best suited for complex, independent, and business-critical applications.

Dual Run

For systems with higher risk or deep integrations, the dual run migration approach is used. In this method, both old (legacy) and new (modern) systems run together for a period. Gradual validation and cut-over help safely replace the legacy system.
Though it may look like the Strangler pattern, it’s different — dual run keeps both systems fully active in parallel during transition.

Data first

For data-heavy applications that are tightly linked to databases, migration needs extra care. First, the database is assessed and moved to the cloud before migrating the connected applications. The database may be modernized or switched to a new type (e.g., Oracle to Azure SQL). During early testing, the old app connects to the new cloud database to check for issues. Temporary data sync is used for a short time to help identify problems and plan rollbacks if needed. Only small changes are usually needed in the app during this phase.

App first

In this approach, applications are moved to the cloud first, while the databases stay on-premises — especially when they can’t be migrated, like data warehouses or mainframe systems. The cloud apps still connect to the original databases using shared servers.
Design must carefully handle any latency issues between cloud and on-prem systems.
This method helps organizations adopt cloud widely while keeping consistent deployment and release processes.