Migrations fail in predictable ways. A dependency nobody mapped, a cutover with no rehearsed way back, a performance problem discovered in production because the test was a ping, or an application that moved successfully and then had nobody to operate it. None of these is a technology problem.
This page describes how the work is sequenced to make those outcomes unlikely. It covers a migration of infrastructure and the workloads on it. Where the thing being modernized is specifically a Drupal estate, the application layer belongs to Enterprise Drupal Modernization and this page is the platform underneath it.
The sequence
Assess, discover, architect, plan, migrate, validate, optimize, operate. The order is not arbitrary: each stage produces the input the next one needs, and the stages most often compressed are the two at the front, which is why the failures appear at the back.
Assess and discover: find the dependencies you do not know about
An inventory of servers is not an assessment. What matters is the dependency graph: which services call which, what runs on a schedule, what integrates outside the organization, which shared components would take several applications with them, and what holds state.
Discovery is the part where automated tooling genuinely helps, because the dependencies that break migrations are the undocumented ones, and undocumented means nobody can tell you about them. Network flow data over a period long enough to include month-end and quarter-end is usually more revealing than any architecture document, precisely because it records what happens rather than what was intended.
Two outputs matter. The first is a workload list with an owner and a business criticality against each entry. The second is a list of things nobody can account for, which is always longer than expected and is the real product of this stage.
Architect: decide the disposition of each workload
Both major cloud providers publish a vocabulary for migration dispositions, and the vocabulary is useful less for its precision than for forcing a decision to be made per workload rather than defaulted. The common set covers rehost, replatform, refactor, repurchase, retire and retain. AWS Prescriptive Guidance sets these out, and Microsoft structures the same decision within its Cloud Adoption Framework.
- Rehost. Move as it is. Fastest, lowest risk, and it carries every existing inefficiency with it. Appropriate where the driver is a deadline such as a data center exit.
- Replatform. Move with a contained change, typically a managed database or a supported operating system version. The best return per unit of risk in most estates.
- Refactor. Rework the application. Expensive, and worth it only where the application is strategic and its current shape is the constraint.
- Repurchase. Replace with a service. Often the right answer for commodity functions, and frequently resisted for reasons that turn out to be sunk cost.
- Retire. Switch it off. Every large estate contains workloads nobody needs, and a migration is the only moment anyone will look.
- Retain. Leave it where it is, deliberately, with a recorded reason and a review date. A retained workload is a decision; an unmigrated one is an oversight.
Retire and retain are the two most often skipped, and between them they usually remove a meaningful fraction of the work. Placement across environments, rather than disposition within one, is covered in Private Cloud, Public Cloud and Hybrid Cloud.
Plan: waves, not a weekend
A wave is a group of workloads that move together because they depend on each other, and that can be validated and rolled back as a unit. Sequencing them well is most of the planning effort.
Early waves should be chosen for what they teach rather than for what they deliver. A first wave of low-criticality workloads with real dependencies exercises the runbook, the tooling, the validation and the rollback while the cost of being wrong is low. A first wave chosen because it is the most urgent business system inverts that, and it is a common mistake because urgency is what got the project funded.
Each wave needs a written cutover runbook, a validation checklist that tests function rather than reachability, a rollback with a decision point and a named person who can call it, and a communications plan. The rollback is the part most often documented and least often rehearsed.
Migrate: data is the hard part
Compute moves easily. Data moves according to its size, its rate of change and how long the business can tolerate it being read-only or inconsistent. Those three facts determine the technique, and the technique determines the cutover window rather than the other way around.
Bulk copy with a final delta suits data that changes slowly. Continuous replication with a short switchover suits data that does not. A staged approach with dual writes suits systems that cannot stop, at the cost of significant complexity and a reconciliation obligation afterwards. The wrong technique produces either an unacceptable outage or an unnoticed inconsistency, and the second is worse because it surfaces later.
Whichever is used, the integrity check afterwards should be defined before the migration and run against agreed counts and checksums. A migration that is declared successful because the application starts has verified the least interesting property.
Validate: test the thing that matters
Validation should establish that the workload performs acceptably under realistic load, that its integrations still work in both directions, that its backups are running and restorable in the new environment, that monitoring and alerting are in place, and that access control behaves as intended. Each of these has been the thing that was missed on some migration somewhere.
Performance deserves particular attention, because the failure mode is gradual. Storage characteristics, network latency between tiers and noisy-neighbour effects all differ after a move, and an application that is merely slower rather than broken will be accepted at cutover and complained about for a year.
Optimize and operate: the stage that is usually unfunded
A migration project ends at cutover. The environment then needs somebody to operate it, and the most common post-migration failure is that this was assumed rather than resourced. Cost is the visible symptom, because workloads rehosted at their original size are almost always oversized for the platform they land on, and nothing in a cloud bill removes a resource nobody is using. Cloud Cost Optimization and FinOps covers the correction.
The less visible symptom is operational. Patching, monitoring, capacity and recovery all need owners in the new environment, and the runbooks that existed for the old one are frequently not transferable. Planning the operational transition as part of the migration rather than after it is the single change that most reliably improves the outcome. Infrastructure Monitoring and Management and Server and Operating System Management describe what that transition has to land.
Migration and modernization are two decisions, not one
The two words travel together and describe different commitments. Migration changes where a workload runs. Modernization changes what it is. Conflating them is how a project scoped as an infrastructure move acquires an application rewrite, and how a rewrite gets justified as a move.
Keeping them separate is usually the cheaper path. Migrate first on a rehost or replatform disposition, stabilize, then modernize selectively against a business case that stands on its own. The argument against is that you touch each workload twice. The argument for is that a migration with a deadline and a rewrite with an unknown end date are different risks, and combining them means the deadline governs the rewrite.
There are exceptions. A workload that cannot run on supported infrastructure in its current form has to change to move at all. A licensing model that becomes punitive on the target platform can make replatforming the cheapest option rather than an improvement. Both are reasons to modernize during the migration, and both should be stated as reasons rather than absorbed into scope.
Deciding not to migrate
The assessment should be able to produce a recommendation against moving a workload, and a process that cannot produce that answer is not an assessment. Latency to a physical dependency, a regulatory constraint on data location, a licence that does not travel, or hardware with several years of depreciation left are all legitimate reasons to retain, and recording them is what turns a gap in the migration into a decision.
Retained workloads still need a plan. A workload left in place without a review date becomes the reason a data center contract is renewed for another term, which is frequently the outcome the migration was funded to avoid.
What LABUSA brings to it
LABUSA has designed and configured hybrid web architectures that use AWS for production workload delivery and additional capacity alongside privately hosted infrastructure, and operates hybrid infrastructure combining private infrastructure with AWS, AWS GovCloud (US) and Microsoft Azure services. Migration work here is therefore done by people who also operate the result, which removes the gap between the party that designs a cutover and the party that lives with it.
The methodology in full is in Building a Cloud Migration Strategy, and the migration and operations service that follows is where the environment is held afterwards.