iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
At scale, changing an application’s execution environment is not one migration project with one method. It is a portfolio decision: assess each workload, choose how much to change, and move related workloads in coordinated waves. Some applications can move with little alteration; others may need selective platform changes, replacement, or a deliberate redesign. Treating every system as a candidate for the same destination or process adds cost and risk without guaranteeing a better outcome.
Choose a migration strategy for each workload
A large-scale application migration starts by deciding what should happen to each workload—not by assuming every application must be modernized in the same way. AWS Prescriptive Guidance describes seven portfolio strategies, often called the “seven Rs.” They are options, not sequential stages every application must pass through.
| Strategy | What changes | When it may fit |
|---|---|---|
| Retire | The workload is shut down. | The application or capability is no longer needed. |
| Retain | It stays where it is for now. | A dependency, requirement, or business constraint makes a move unsuitable or premature. |
| Rehost | The application moves with minimal application change. | The priority is moving the workload without redesigning it. |
| Relocate | Servers or other platform resources move across a platform boundary. | The workload can move as a unit without changing its application design. |
| Repurchase | The existing application is replaced with another product or service. | A replacement better fits the business need than continuing to operate the current application. |
| Replatform | Selected changes or optimizations are made while moving. | A limited amount of change can improve the target fit without a broader redesign. |
| Refactor or re-architect | The application’s architecture changes more substantially. | The intended business or technical outcome justifies the additional work and risk. |
AWS identifies refactoring as the most complex and costly of these strategies in its large-migration guidance, and recommends it only when other options are unacceptable in that context. That is AWS guidance, not a universal rule: the right choice depends on the workload’s requirements and the outcome the organization needs.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallAssess the workload before assigning it to a wave
Workload discovery should establish the constraints that determine both the migration strategy and the sequence. Google Cloud’s workload-assessment guidance recommends grouping workloads and data into batches, choosing batch order, and sequencing workloads within each batch. As discovery improves, revise the groupings and order rather than treating the first plan as fixed.
- Business fit and expected value: Is the application still needed, and what outcome should moving or changing it deliver?
- Dependencies: Which applications, services, data stores, and teams must move or coordinate together?
- Data and workload characteristics: How much data is involved, how does it change, and how large or demanding is the workload?
- Downtime tolerance: What interruption can users and business operations accept?
- Change and operating requirements: How often does the application change, and can the team operate it in the target environment?
- Security and compliance: Do the source and target environments meet the workload’s obligations?
- Cost and recovery: What will the chosen path require, and how difficult will it be to recover or move forward if a step fails?
Google Cloud notes that zero- or near-zero-downtime approaches are usually more costly and complex than approaches that allow downtime. Treat that trade-off as a business decision: add the complexity when the service requirement warrants it, not simply because minimizing downtime sounds better in isolation.
Useful planning artifacts include a technical design, a responsibility matrix, and a timeline. They make dependencies, ownership, and decision points visible before teams begin moving a batch.
Use migration waves and a factory to repeat the work
A migration factory is an operating model for scaling repeatable implementation and operations through automation, release planning, and concurrent teams. It is most useful when assessment reveals recurring patterns that teams can standardize; it is not a single architecture that every workload must adopt.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →AWS Prescriptive Guidance’s migration-factory model distinguishes work by complexity. High-volume, low-complexity rehosting can use repeatable processes. Replatforming can use standardized patterns where the changes recur. Complex or core-application refactoring needs planned release cycles and participation from application owners. Applying a high-throughput process to a difficult redesign can erase the very ownership and coordination that work requires.
- Build a current inventory. Keep workload information current enough to identify dependencies, constraints, and changes in readiness.
- Form batches around real dependencies and patterns. Group workloads that should move together, then order both the batches and the work within each batch.
- Standardize repeatable tasks. Automate steps that recur, while leaving workload-specific design and approval decisions with the responsible teams.
- Plan releases and ownership. Align each wave with application-owner availability, validation, and cutover responsibilities.
- Maintain a reprioritizable backlog. AWS recommends an adaptable release-management plan and a backlog that teams can reprioritize when schedules are disrupted.
- Update the plan as discovery continues. Increase or reduce batch sizes and change sequencing when new dependencies or constraints emerge.
Decide whether to move first or change the architecture too
Moving an application and changing its internal design are separate decisions. Rehosting can shift the execution environment while preserving the application. Replatforming introduces selected changes. Refactoring changes the design more broadly. These choices can be made for different workloads in the same portfolio, and not every move needs to become an architecture program.
When gradual replacement is appropriate, the Strangler Fig pattern provides a way to shift functionality incrementally. A façade or proxy routes requests to the existing application and the replacement. Initially, most traffic can continue to the old system; as each capability is ready, routing can move progressively. The old application remains functional while both implementations coexist, so routing rules, observability, and ownership need to stay clear throughout that period.
In her 24 April 2018 article “How to break a Monolith into Microservices,” Zhamak Dehghani wrote: “Each step of migration represents an atomic improvement to the overall architecture.” That is an architectural perspective, not a guarantee that incremental decomposition is always cheaper or safer. Before breaking a monolith into services, decide whether decomposition is appropriate at all—and whether microservices are the right destination. Also define how and when each replaced path will be retired; a new service that leaves the old code path in place indefinitely can add complexity rather than remove it.
Free tools Windows power users keep installed
One-click scans. No signup required.
Plan data movement around consistency and ownership
Application migration and data migration must be coordinated. Google Cloud’s database-migration guidance distinguishes a migration, which has an intended end state where clients use the target and the source may be turned down, from replication, which can continue without a planned completion point.
For a selected dataset, a consistent migration means the target contains the required data, has no duplicates, and applies source changes in their original order. If both source and target accept writes in an active-active arrangement, conflicting updates become possible; teams need explicit conflict-resolution rules.
For a shared monolithic database, Microsoft’s Strangler Fig example illustrates a staged approach:
- Introduce a service for one domain while it still uses the existing database.
- Create a database isolated for that domain and load historical data with ETL.
- Synchronize ongoing changes using change data capture (CDC).
- Validate consistency before switching reads and writes to the new database.
- Remove old tables, procedures, and dependencies only after validation and after deciding the old structures are no longer needed for rollback.
Set the data rules before cutover: define what counts as complete, how duplicates are detected or handled, how changes are ordered, and which system owns writes at each point. If those rules are left implicit, a successful copy alone does not establish that the target is safe to use.
Make cutover and rollback explicit
A cutover is a controlled change in which clients begin using the target. AWS Prescriptive Guidance lists an ingestion freeze, final backup, final data synchronization, and routing change among cutover activities. The exact sequence depends on the system, but the decision points and recovery path should be defined before the change begins.
Best Value
- Freeze or otherwise control incoming changes as specified by the migration plan.
- Take the planned final backup.
- Complete final synchronization and validate the required data.
- Change routing so clients use the target.
- Monitor the target and follow the agreed recovery procedure if validation or operation fails.
A clean reversal may be possible when no data has changed after cutover. Once the target accepts new transactions, the source may be stale, so pointing traffic back can lose or misplace writes. Depending on the design, recovery may require fail-forward replication, dual writes, or native backup and restore. AWS recommends testing backup and restore in lower environments before cutover.
Near-zero-downtime transfers have their own operational condition: source updates must be processed quickly enough to keep up. Google Cloud’s database-migration concepts also call for a way to resume from a known consistent point if the migration system or a database fails. Therefore, a claim of “zero downtime” or “instant rollback” is meaningful only when the write path, synchronization lag, consistency checks, and recovery procedure support it.
Do not remove old database objects or synchronization paths until the new path has been validated and the team has deliberately ended its rollback need. Microsoft notes that rollback becomes substantially harder after those structures are removed because restoring them and replaying changes may be necessary.
Turn portfolio choices into a controlled program
The central management task is to match each workload’s requirements to a migration path, then coordinate related work in waves. Use repeatable processes for genuinely repeatable moves, reserve planned releases and application-owner participation for complex redesigns, and treat data consistency and recovery as part of the design—not as tasks to improvise at cutover.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
