Hello, I'm Maneshwar. I’m building LiveReview, a private AI code review tool that runs on your LLM key (OpenAI, Gemini, etc.) with highly competitive pricing -- built for small teams. Do check it out and give it a try!
Migrating applications, data, or entire infrastructure is one of the most challenging phases in a system’s lifecycle.
Whether you’re moving from on-premises servers to the cloud, switching between cloud providers, or breaking down a monolith into microservices, the process involves risk, coordination, and careful planning.
In this post, we’ll go over migration strategies, the problem with database updates, and practical approaches like backwards-compatible schema changes and separated data sources.
Core Migration Strategies
When planning a migration, there are six commonly recognized approaches—each with different trade-offs:
Rehost (Lift and Shift)
Move applications “as-is” with minimal changes. Fastest option, but doesn’t leverage full benefits of the new platform.Replatform
Make small optimizations (e.g., switching to managed services, scaling improvements). Retains most architecture while improving performance.Refactor
Redesign applications to fully exploit new platform capabilities (cloud-native features, microservices, serverless). More time-intensive, but higher ROI.Repurchase
Replace legacy applications with modern, usually SaaS-based solutions. Example: moving from a custom CRM to Salesforce.Retain
Keep certain applications in their current environment due to cost, complexity, or compliance.Retire
Decommission applications that are redundant or obsolete.
These strategies aren’t mutually exclusive—you often apply different approaches to different parts of a system.
TL;DR
- Favor backwards-compatible schema changes where possible
- Each deployment unit should have separated data sources
- Use tools for schema updates and migrations (Flyway, Liquibase)
- Relational DBs: schema migration is complex but manageable with automation
- NoSQL DBs: no schema updates needed, but you may still need to migrate data
- Easy mode: Maintenance window + downtime
- Hard mode: Zero downtime → requires stepwise deployment + intermediate versions
The Problem with Database Updates
Unlike application updates, databases are hard to change:
- Existing data must be adapted—difficult if datasets are large
- Rolling back schema changes is often impossible
- Realistic testing is hard because test DBs rarely mirror production scale
- Frequent deployments (Continuous Delivery) make the problem worse
This is why database migration strategy becomes just as important as application migration strategy.
Backwards-Compatible Schema Changes
Think of your schema as an interface. If you break it, everything depending on it breaks too.
Two examples of keeping DB updates backwards-compatible:
- Adding a column: Applications unaware of the column still function if defaults are used.
- Removing a column: First make it optional, then gradually update applications to stop using it before final removal.
This allows you to deploy database changes independently from application changes—critical for microservices and continuous delivery.
Separated Data Sources
The hardest migrations happen when multiple applications share the same database.
- Shared Database: Updating schema requires coordinating all dependent applications at once—painful and error-prone.
- Separated Databases/Schemas: Each service owns its own data source. Database changes only impact one application, making migrations easier.
This separation is one of the main drivers behind microservices—you can deploy and evolve services independently.
Schema Updates and Data Migration
Relational Databases
- Schema changes require migrations
- Tools like Flyway, Liquibase, DbMaintain automate schema versioning and updates
- Migration scripts are tracked in meta tables, making schema evolution consistent across environments
NoSQL Databases
- No fixed schema → old and new structures can coexist
- Applications must handle flexible data (e.g., a field may exist or not)
- Reduces need for schema migrations, but you may still need data migrations for consistency
Deployment Scenarios
1. Maintenance Window (Downtime Allowed)
- Shut down app
- Update DB schema
- Deploy new app version
- Restart services
Straightforward, but not acceptable for high-availability systems.
2. Zero Downtime (High Availability)
- Requires blue/green deployments or rolling updates
- Database changes must be incremental and backwards-compatible
-
Complex changes (like renaming a column) require multi-step deployment:
- Add new column → write to both columns → migrate data → switch reads → drop old column
This process is laborious but avoids service disruption.
NoSQL Data Migration Scenarios
- Simple Changes (e.g., changing a field type):
- Application can handle both types, no immediate migration needed
- Later migration for consistency
- Complex Changes (e.g., restructuring documents or collections):
- Requires data migration since queries depend heavily on data layout
- More frequent in NoSQL due to query inflexibility compared to relational DBs
Final Thoughts
Application migration is already tough, but databases are where migrations get really tricky. By following strategies like backwards compatibility, separated data sources, and using migration tools, you can reduce risk and support continuous delivery.
Choose the right migration approach (Rehost, Refactor, etc.) for each system component, and always plan your database strategy as part of the overall migration—not as an afterthought.
LiveReview helps you get great feedback on your PR/MR in a few minutes.
Saves hours on every PR by giving fast, automated first-pass reviews.
If you're tired of waiting for your peer to review your code or are not confident that they'll provide valid feedback, here's LiveReview for you.
Top comments (0)