Forty Applications and a Lease That Ends in March

The situation

A regional insurer runs 40 applications out of a single leased data centre. The lease ends on 31 March and the board has decided not to renew it. That leaves roughly seven months, one infrastructure team of six, and no new headcount.

The estate is the usual mix. Eleven applications are Windows servers running a vendor product, patched but untouched for years. Nine are internal Java services against Oracle. Six are departmental things somebody built in Access a decade ago and nobody will admit to owning. Four are the claims platform, which is where the revenue is. Three are a CRM that the sales director has complained about since before anyone can remember. The remaining seven are batch jobs, an internal wiki, and a set of servers that appear in the inventory with no owner and no documentation.

Nobody can say with confidence which of the 40 talk to each other. The wiring closet has had fifteen years to accumulate undocumented dependencies, and the last person who knew them left in 2023.

What actually matters

The first thing to settle is that the migration strategy is chosen per application, not for the estate. A programme that picks one answer for 40 applications gets it wrong 39 times. Some of these should be rewritten, several should be moved untouched, and a few should be switched off, and the only way to know which is which is to look at each one against the clock and the business case.

Then there is the clock itself, because it changes what counts as a good answer. With seven months and six people, effort is the binding constraint rather than elegance. A strategy that produces a better end state but consumes four of the seven months on one application has used the programme’s capacity on 2.5% of the estate. The strategies involving least change are the ones that let the deadline be met. The ones involving most change have to be reserved for applications where the business case justifies them. That is what the seven strategies make visible: they are ordered by how much change each one involves, so choosing one is choosing a level of effort.

Discovery deserves its own line because it gates everything else. Six applications have no identified owner and nobody can draw the dependency map. Moving an application whose callers are unknown is how a migration takes down a system nobody connected it to. Dependency data also sets the order of the moves and the shape of the cut-over windows, and it is what turns “nobody uses this” from an assumption into a measurement. An estate this size does not get discovered by asking people; it gets discovered by instrumenting the servers and watching what talks to what for a few weeks.

The last thing worth weighing is what happens after March. A rehosted Windows server in the cloud is still a Windows server somebody has to patch, and the team still owns the operating system, the backups and the capacity planning. Choosing the fastest route for everything means arriving in April with 40 applications that cost more to run than they did before and deliver nothing new. The realistic plan moves the whole estate before the lease ends and improves the handful where improvement is worth the work, rather than treating the deadline as the only requirement.

What we’ll filter on

1. Fits inside seven months with a team of six, counting the discovery time.
2. Reduces the operational work the team owns afterwards, or at least does not increase it.
3. Does not require application source code changes where no code or vendor support exists.
4. Has a business case proportionate to the effort, rather than being change for its own sake.
5. Leaves the application supportable in April, with an owner, a runbook and a backup.

The landscape

Rehost moves the server as it is. Block-level replication copies the disks to AWS while the source keeps running, and cut-over is a short window while the replicated copy launches on EC2. It is the fastest route and the one with the least risk to application behaviour, because nothing about the application changes. What it does not do is reduce anything: the same operating system, the same patching, the same backup job, now on an EC2 instance.

Replatform moves the server and swaps one or two components for managed equivalents on the way. Self-managed MySQL becomes Amazon RDS, a hand-built load balancer becomes an Application Load Balancer, a cron host becomes Amazon EventBridge Scheduler. The application code is usually untouched or nearly so. The work is in the plumbing and the testing. Afterwards the managed service handles the patching, the backups and the failover that the team used to run itself.

Repurchase abandons the application and subscribes to a product that does the same job. There is no migration in the infrastructure sense; there is a data export, a data import, a configuration project and a set of users who need retraining. The effort lands on the business rather than on the infrastructure team, which is a real consideration when the infrastructure team is the constraint.

Refactor rewrites the application against cloud-native services. It produces the best end state and involves far more work than any other route. AWS calls it the most complex and costly of the seven, and for a large migration recommends modernising after the move rather than during it. Under a seven-month deadline it is defensible only for something already funded and already under way, and even then the rewrite and the migration are usually separated: move it first, rewrite it after, so the deadline does not depend on a software project.

Relocate moves a group of servers to a cloud version of the same platform without converting the virtual machines or changing the applications on them. For a VMware farm that means Amazon Elastic VMware Service, which runs VMware Cloud Foundation on EC2 bare metal instances inside your own VPC. The older path, VMware Cloud on AWS, stopped being sold by AWS in April 2024 and is now a Broadcom subscription, so it is not something to plan a new programme around. Relocate suits an estate that has to arrive intact, and it carries the hypervisor layer along with everything else.

Retain leaves an application where it is. With the data centre closing this is available only in a narrow sense: retain means postponing a decision, so it applies to something moving to a different destination, or something being retired shortly after March on its own schedule.

Retire switches the application off. AWS puts the typical finding at more than 10 percent of an enterprise portfolio no longer serving any purpose, and gives blunt tests for spotting it: no inbound connection for 90 days, or average CPU and memory below 5 percent. Every retired application is capacity handed back to the programme.

Three services do the supporting work, and the names moved recently. AWS Transform runs discovery and wave planning: agent-based and agentless collectors inventory the servers, map the dependencies between them, and group applications into waves. It is the replacement for AWS Application Discovery Service and AWS Migration Hub, which both closed to new customers on 7 November 2025 and so are not available to a programme starting now. AWS Transform MGN, renamed from AWS Application Migration Service, performs the rehost through continuous block-level replication. AWS Database Migration Service moves the databases with the source online, and its schema conversion feature, or the downloadable AWS Schema Conversion Tool, converts the schema first when the target engine differs from the source.

Evaluation

Side by side

Strategy	Fits the window	Reduces ops work	No code changes needed	Proportionate effort	Supportable in April
Rehost	✓	✗	✓	✓	✓
Replatform	✓	✓	✓	✓	✓
Repurchase	✓	✓	✓	✓	✓
Refactor	✗	✓	✗	✗	✓
Relocate	✓	✗	✓	✓	✓
Retain	✗	✗	✓	✓	✗
Retire	✓	✓	✓	✓	✓

No row wins outright, because no single strategy is right for all 40 applications. Rehost and retire are what let the deadline be met. Replatform and repurchase are what stop the estate arriving unchanged. Refactor is the one the deadline rules out. Retain fails the April column for a specific reason: with the lease gone there is nowhere to retain it.

Sorting one application

The solution

Run discovery before committing to any of it. AWS Transform collects from both directions: an agent on each server records running processes, inbound and outbound connections and time-series performance, while an agentless collector reads configuration and utilisation out of vCenter without touching the guests. Run it for several weeks. That produces three things the programme cannot proceed without: a dependency map saying which applications have to move together, utilisation data telling you what size the instances need to be rather than what size they currently are, and evidence for the retire decisions. The six unowned departmental tools are where that evidence lands fastest, because an application with no inbound connection over 90 days is one nobody has to migrate.

Sort the survivors into waves, and do the retire wave first. Every application switched off in October is one not competing for the team’s time in February. Then the rehost wave, because it is the highest-volume and lowest-risk work and it can run largely in parallel. AWS Transform MGN replicates the eleven vendor Windows servers block by block while they keep serving, so the cut-over window runs to minutes rather than an extended outage. Those eleven change nothing about their operating system or their patch burden, and the team accepts that, because those eleven have to leave the building on time.

The nine Java services are the replatform wave, and they are where the estate actually improves. Oracle moves to Amazon RDS, with AWS Database Migration Service replicating while the source stays online. If the target engine is Oracle on RDS, DMS is all that is needed. If the business case supports moving to Aurora PostgreSQL, a schema conversion step comes first: DMS Schema Conversion converts the tables, views and stored procedures, and DMS then carries the data. That route is more work and removes the Oracle licence cost, so it is a business decision rather than an infrastructure one.

The CRM is the repurchase, and it should be started early and run by the sales function rather than by the six people doing the migration. The work is data export, data mapping, configuration and retraining. It consumes almost none of the infrastructure team’s capacity, which is the reason to identify it in October rather than discover it in February.

Track everything in one view rather than in a spreadsheet on somebody’s laptop. AWS Migration Hub was the service for that and is closed to new customers, so the tracking now sits in AWS Transform alongside the discovery data and the wave plan. That view is where the programme’s weekly report comes from, and where the board sees whether 31 March is still achievable.

Leave the claims platform alone. It is the revenue system, it is the one with the strongest case for a refactor, and it is the worst possible thing to rewrite against a lease expiry. Rehost or replatform it in this programme and fund the rewrite separately, on a timeline that a software project can actually hold.

What’s worth remembering

1. The seven strategies are chosen per application, not per estate, and they are ordered by how much change each involves: retire and rehost need the least, refactor the most.
2. Rehost moves the server untouched and reduces nothing operationally; replatform swaps a component for a managed equivalent and is what takes work off the team.
3. Repurchase means subscribing to a different product, which moves the effort onto the business rather than onto the infrastructure team.
4. Refactor produces the best end state and is the wrong answer under a hard deadline; move first, rewrite on its own schedule.
5. Discovery comes before strategy, and it supplies the dependency map, the utilisation data for rightsizing, and the evidence behind every retire decision. AWS Transform does that work now; Application Discovery Service and Migration Hub closed to new customers on 7 November 2025.
6. DMS moves the data with the source online, and a schema conversion step is only needed when the target engine differs from the source.