Migration Strategy and Estate Assessment

The hospital group’s migration plan used a configuration database listing 203 systems mapped to 299 hosts. Discovery found 340 hosts; reconciling stable asset identifiers with the register exposed 41 unregistered hosts. They included a server running a nightly batch that rebuilt the bed-management view from four sources, a departmental file share used by nine clinics for scheduling, and an imaging license server. The initial pharmacy wave went ahead before the team had explained those gaps. On its first night, the batch read the pharmacy database through an obsolete hard-coded address and produced an empty bed view. The pharmacy system had few recorded dependencies, but the plan had missed a consumer. The program manager’s incident note became a reminder: we planned against what we had written down, not everything that relied on it.

The hospital and its figures are fictional. System counts and host counts measure different things; their mapping, rather than the difference between the totals, reveals omissions. Migration, modernization, and transformation make different promises. Assessment connects those promises to evidence about the estate, data, operations, and dependencies. Program goals and constraints guide the overall application strategy; component-level choices then describe how to implement it, potentially in stages. That work also determines which workloads to group and which candidates can provide useful early learning at acceptable risk.

Start from what is running, not what is written

Google’s assessment guide recommends an inventory that covers workloads and their dependencies, checked with the people who design and operate them. GOV.UK similarly cautions that existing documentation may not describe the full environment. Assess each legacy system against its actual support, maintainability, cost, and risk conditions; age alone does not select its migration strategy. The authors of Patterns of Legacy Displacement recommend enough understanding of systems and business activity to choose an initial direction without getting trapped in exhaustive detail. For the hospital, the following views organized that investigation; they are a practical grouping of evidence, not a required database schema. The existing register provided useful application and host records but left gaps across these views.

Layer	What it lists	Where the evidence comes from	What the hospital was missing
Workloads	Applications and services, with source location and whether it can be modified, deployment method, how clients reach them, how they authenticate	The configuration database, corrected by discovery tooling and by the teams that run each one	Forty-one hosts nobody had registered, including the licensing server
Dependencies	Databases, brokers, configuration stores, file shares, scheduled jobs, and the other workloads each one reads or writes	Network discovery for what talks; code, job schedulers, and owners for why; observation covering relevant business cycles, supplemented by job definitions, historical records, and owner checks	The nightly batch; the file share the clinics scheduled on
Supporting services	Source repositories, build and deployment pipelines, artifact stores, backup, monitoring, identity	The platform and operations teams	A backup system with a retention obligation nobody had written into the plan
Hardware and appliances	Servers, network devices, firewalls, dedicated hardware, with vendor, model, and support status	Asset records checked against what discovery can see	Two imaging workstations on an unsupported operating system that could not be moved and had to be retained

Google’s inventory scope includes supporting infrastructure as well as workloads. The legacy displacement authors also emphasize users and the workarounds that cross system boundaries. A scheduler explained the clinics’ file share; traffic alone would not have established its business role. AWS’s portfolio guide treats assessment as continuing work, with explicit gaps in the initial view and more detailed evidence for upcoming migrations. Combine discovery with asset records, code, schedules, contracts, and owner knowledge. Record what was observed, when, and what the tools cannot see. An offline host or an annual manual export may be absent even from a long observation window. Prioritize unresolved gaps by their possible impact on the next move, not merely by how few remain.

Dependencies in both directions

A system dependency exists when one component needs another’s data, behavior, availability, or decision. Trace both what the migrating component needs and what needs it. The hospital missed the batch’s dependence on the pharmacy address. GOV.UK identifies interdependence and incomplete documentation as migration obstacles. Inspect runtime calls for address, protocol, access, and latency assumptions; shared data for authority and consistency; scheduled or manual flows for business timing; and shared services for the particular consumers they support. Moving a consumer does not necessarily split its data: the original store may remain authoritative. If data is split or replicated, define the intermediate states explicitly. Identity, backup, monitoring, and licensing may be retained, moved, replaced, or temporarily bridged. Their location alone does not establish compatibility. Impact analysis turns the evidence into a list of dependents and owners with stated coverage limits. Notify and consult those owners, then verify their affected flows and acceptance conditions; notification alone is not validation.

What the data and the operation constrain

Data and operational requirements constrain the target and the transition. Google’s assessment guide identifies geographic and tenancy restrictions, deployment methods, licenses, and tolerance for interruption or data loss. GOV.UK emphasizes understanding data assets and their schemas. Record the applicable requirement and its source rather than inferring it from a broad label. A data classification helps identify handling needs but does not by itself determine every permission or retention deadline. Evaluate deployment reproducibility separately from automation: a controlled manual procedure can be repeatable, while an automated pipeline can still depend on undocumented state. Test the artifacts, settings, credentials, and recovery procedure that the target will need. Image-based rehosting is an option, not an exemption from those tests. Confirm how licenses apply to the target and what availability and data-loss limits the business has approved.

Constraint	Question to answer per component	What it rules out or forces	Where the hospital found it
Residency and classification	Where may this data be stored and processed, and under what classification?	Regions, providers, and shared tenancy; sometimes retention on premises	Patient records constrained to the country; one research dataset under a consent that forbade a third-party processor
Retention and access	What must be kept, for how long, and who must still be able to read it?	Archive before retirement; the backup system’s own migration or continued reach	Seven-year retention on a system scheduled for retirement
Schema and meaning	Is the schema known, and does the data mean what the documentation says?	Discovery before any conversion; reconciliation criteria written before the move	A pharmacy field reused for two purposes since 2014
Deployment	Can the team reproduce and recover this deployment using controlled artifacts, settings, and procedures?	Test the chosen manual, automated, or image-based method; record operator dependencies and residual risk	Eleven systems previously deployable only by one contractor
Licensing	What do the terms permit, and how are they counted?	Repurchase, retain, or renegotiate; nothing moves until the answer is known	The imaging license, counted by socket, on a server that would not exist
Availability during the move	What downtime and data loss can this tolerate, and when?	A transition design that meets the approved interruption and data-loss limits; a maintenance window where permitted	Emergency-department systems: none; the finance ledger: a weekend

Seven strategies across applications and components

AWS’s seven Rs describe migration approaches: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Its application design guidance calls for an overall strategy and the strategies of individual components, including staged moves. One application may combine rehosting of supported servers with replatforming of a component whose operating system is unsupported on the target. Record those choices against business goals and constraints, and revise provisional choices when detailed design exposes a blocker. Lift and shift preserves the application while changing its hosting environment. The other strategies change different parts of the system or its use, but none is a formula for technical-debt reduction. Identify the particular problem, what the proposed change removes, and what burden or obligation remains. A new implementation can also introduce new debt.

Strategy	Choose it when the assessment shows	What to change and verify	The hospital’s use
Retire	The capability is no longer needed or is replaced, and remaining consumers and obligations can be satisfied	Remove the running service only after dependency, records-access, controlled-stop, and recovery checks; retained data and integrations can still need maintenance	Thirty-eight of the forty-one unregistered hosts, and twenty registered ones
Retain	A current constraint or the option comparison favors staying in place for now	Keep necessary maintenance and risk controls; record the reason, owner, and reconsideration conditions	The two imaging workstations; the finance ledger pending its vendor’s cloud option
Rehost	The target can support the application and an unchanged application move fits the goal or a staged plan	Verify target behavior and operations; application problems may remain. Assign resources and timing to approved deferred work	One hundred and ninety hosts across six later waves
Relocate	An existing platform can move to a compatible target with acceptable transition conditions	Validate platform compatibility, access, operations, and costs; application debt may remain and speed depends on scope	The virtual desktop farm
Repurchase	A product meets required functionality and the full adoption and exit costs are acceptable	Validate product fit, data, integrations, access, user and process changes, and old-system retirement; old code is not the only source of burden	The clinics’ scheduling, replacing the file share and a custom tool
Replatform	A platform change addresses supportability or an identified operational problem	Test the intended improvement and remaining application constraints; managed operation can reduce some work while adding integration obligations	Nine databases to a managed service; the batch server’s operating system
Refactor	Architecture changes are justified by the required outcome and acceptable alternatives are insufficient	Validate the specific problems addressed, compatibility, new operating demands, and remaining debt; estimate cost and risk for this scope	Bed management, rebuilt around events instead of the nightly batch

For large migrations, AWS generally favors rehosting, relocating, or replatforming before later modernization, and recommends refactoring when the other strategies are not acceptable. This is a conditional planning recommendation, not a required small percentage of refactors. The legacy displacement authors describe failures in which an unexamined promise to reproduce all existing functionality encouraged a large single cutover. That warning does not remove the need to preserve approved behavior or reconcile results. Component-level choices create options for phased work, but do not guarantee it: a rehost can still require a coordinated switch, and an application may need extensive redesign. Decide change scope and transition sequencing separately, using the interfaces and intermediate states the design can actually support.

Waves: what moves together, and what moves first

A migration wave groups workloads and data for coordinated migration. Google distinguishes ordering the groups from ordering workloads inside each group. Use dependencies, business value, team capacity, licensing, availability, and change effort to choose the composition. Members need not switch simultaneously, and preparation for one wave may overlap stabilization of another where the dependencies and staffing permit it. At each step, validate the required interfaces, permissions, latency, and data authority, whether a dependency is in the same wave, already moved, or retained elsewhere. The pharmacy incident was a failure to discover and preserve a consumer’s contract, not simply a failure to place both systems in one wave. Revise size, order, and membership as evidence improves; a later wave may remain small or become smaller when its potential impact is greater.

A first mover is an early migration candidate selected partly for the learning it can provide. Google recommends lower business risk, representative patterns, observable use, manageable dependencies, limited refactoring, and fewer licensing or compliance obstacles. These are selection preferences to weigh against the program’s constraints, not a definition excluding every exception. Motivated teams need clear goals, sponsorship, and enough capacity to investigate failures. AWS’s discovery guidance gives three to five applications as an example of an initial candidate list, not a mandatory batch size. After its failed pharmacy wave, the hospital selected a staging environment and two internal reporting services for the first wave of the revised plan. Their shared deployment pattern supported useful learning, but production scale, stateful behavior, and different failure conditions still required separate validation.

Before authorizing a move, bring together dependency evidence, applicable constraints, strategy decisions, and cutover and coexistence arrangements. Use this evidence together to decide whether the affected move is ready. It may be maintained in linked records rather than a prescribed set of separate documents, and it does not define what constitutes a wave. Readiness depends on the agreed tests: for example, reconciliation at an approved data position, consumer and access checks, performance acceptance, recovery rehearsal, and a named decision owner applying stop criteria. Record open risks and who can accept them; unresolved mandatory conditions block the affected move. A wave may exist in a plan long before it is ready to execute. AWS’s application design guidance also recommends reusable approval patterns to reduce review effort at scale, while retaining assessment of the particular application and its operational readiness.

Judging an assessment and a strategy

Assess the evidence behind the plan. The inventory should connect systems to hosts and supporting assets, identify its sources and blind spots, and give consequential gaps an owner and response. Dependency records should include both directions, relevant business cycles, and confirmed consumer requirements. Strategy decisions should explain alternatives and staged choices at the application and component levels; their quality is not measured by the fraction labeled refactor. For each proposed wave, inspect transition contracts, test results, recovery options, staffing, and unresolved risks. A recent revision date shows when a record changed, not whether its contents are correct. The configuration database, discovery results, and owner knowledge are complementary evidence; none alone proves readiness.

What a reviewer should ask

1. How do systems map to hosts and supporting assets, which records were reconciled, and what significant gaps remain?
2. For each component in the next wave, what depends on it, who owns each dependent, and which affected contracts have been tested and accepted?
3. Which scheduled and manual flows were confirmed, what periods and sources were examined, and what could still be missing?
4. Which data may not leave where it is, which must be kept beyond a system’s life, and where is that recorded?
5. Which deployment and recovery procedures have been reproduced, what operator dependencies remain, and how do the licenses apply to the target?
6. What overall and component-level strategies were chosen, which stages do they require, and why are the alternatives less suitable?
7. What is in the first wave, and what will the team know after it that it does not know now?
8. When was the assessment last revised, and what changed?

The hospital revised its plan using the mapping from 203 systems to 299 registered hosts and the 41 additional hosts found during discovery. In the first quarter of the revised plan, 38 of those 41 and 20 registered hosts were retired. Owners checked dependencies in both directions, infrequent business activity, retained-record access, controlled stops, and recovery before approving closure. The first wave of that revised plan moved a staging environment and two internal reporting services in five weeks. Its runbook became a starting point for six later waves, with fresh checks for each wave’s scale, data, interfaces, and failure modes. The batch server was replatformed temporarily while bed management was rebuilt. Before the final switch, the team reconciled bed state at agreed data positions, checked event delays and duplicates, rehearsed recovery, and obtained the responsible owners’ acceptance. The batch ran in a controlled comparison arrangement before retirement a month later. The morning shift’s lack of disruption was useful feedback, not the sole correctness test. The configuration database remained the managed register, enriched by discovery, schedules, contracts, and owner evidence. Weekly reconciliation was this program’s chosen cadence, supplemented by change-triggered updates and follow-up on important unknowns.

References:

• Google Cloud Architecture Center, Migrate to Google Cloud: Assess and discover your workloads, last reviewed 2 August 2024 (CC BY 4.0).
• AWS Prescriptive Guidance, About the migration strategies.
• AWS Prescriptive Guidance, Application portfolio assessment guide for AWS Cloud migration.
• AWS Prescriptive Guidance, Discovery acceleration and initial planning.
• AWS Prescriptive Guidance, AWS application design and migration strategy.
• AWS Prescriptive Guidance, Best practices for retiring applications.
• Government Digital Service and Central Digital and Data Office, Managing legacy technology, 2019 (Open Government Licence v3.0).
• Ian Cartwright, Rob Horn, and James Lewis, Patterns of Legacy Displacement, martinfowler.com, updated March 2024.