Migrating Application Hosting to AWS: A Controlled Route from Old Server to Cloud

01

The migration request sounds smaller than the system

Imagine a wholesale parts business running its customer portal and ordering system on one managed server. Traffic is normally predictable, but campaigns create sharp peaks. Product images and customer documents live on the server. Imports run overnight. Payments, email and accounting depend on third party services.

The request sounds simple: move the application to AWS before the next busy period.

The server is only the visible part. The working system also includes its database, uploaded files, user sessions, scheduled jobs, queues, certificates, DNS records, email settings, backup routines, supplier integrations and the knowledge held by the person who has looked after it for years.

Copying the server may reproduce some of that. It does not prove the application will work under load, recover from failure or remain supportable after the old environment is switched off.

A useful migration starts by understanding the application as an operating service. AWS is the destination. The business outcome is a system that can be deployed, observed, recovered and owned with less uncertainty.

02

First decide why the hosting needs to move

The reason for moving determines what a successful migration looks like.

The existing server may be running out of capacity. It may rely on an unsupported operating system. Access could be tied to a former supplier. Recovery might depend on a backup nobody has restored. The application could need capacity for seasonal demand, a stronger deployment process or a more suitable region for its users.

Each problem points to different work. A capacity issue may be solved by application optimisation, better caching or a larger managed server. An ownership problem starts with access and documentation. A resilience problem requires recovery design and testing. An ageing application may need a staged modernisation rather than an immediate infrastructure move.

AWS is useful when its services fit the workload and the business is ready to operate them. It is not automatically the simplest or cheapest answer. A small, stable application might be better served by capable managed hosting. A standard business need may be better met by buying software rather than moving a bespoke application at all.

The decision should be based on the business need, the application constraints and the responsibilities the team is prepared to own.

03

Choose the right kind of move

AWS describes seven common migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. The names matter less than making the choice deliberately.

Relocating a compatible virtual environment can also be useful for some estates, but it is less common for the single inherited business application in our example.

Rehosting is often the quickest route, but speed should not be confused with modernisation. The old patching, deployment and recovery problems can arrive in a newer data centre. Replatforming can remove worthwhile maintenance without rewriting everything. Refactoring offers more freedom but combines application change with hosting change, which makes testing and rollback harder.

When a deadline is real, the sensible route is often to move safely first and modernise in controlled stages afterwards.

04

Discover the application before designing AWS

The architecture should follow what the application actually does, not what an old diagram says it does.

Start with the current environment. Record the operating system, runtime versions, web server, database, storage, memory, scheduled tasks and background workers. Find where configuration and secrets are held. Identify the source repository and how changes reach production.

Then trace the information. Which files are uploaded locally? Where are user sessions stored? Does a scheduled import assume a particular path? Which services call the application by a fixed IP address? Which domains, certificates and email records are involved? What happens when a payment, document conversion or accounting integration is unavailable?

People are part of this map. Confirm who owns the domain, cloud account, source code, deployment keys, supplier relationships and cutover decision. A migration can be technically sound and still fail because the only person with access to a critical account is unavailable.

Finally, capture a baseline. Record normal and peak traffic, response time, error rate, database size, storage growth, backup duration, recovery expectations and current running cost. Without a baseline, the new environment can feel faster while an important background task quietly takes twice as long.

The discovery should leave the business with an evidence based workload map, a risk list and an agreed migration route.

05

Build the AWS foundation before the application

Moving production into a hastily created AWS account creates a future takeover problem.

Set the ownership model first. Use named access, multi factor authentication and roles that grant only the permissions required. Decide how production is separated from development and testing. Establish network boundaries, logging, cost budgets, resource naming, backup policy and the region in which the workload will operate.

Application secrets should have a controlled home. Deployment should be repeatable. Monitoring and alerts should exist before users arrive, not after the first unexplained outage. Logs need a retention period and an owner who knows what should trigger action.

Managed AWS services can reduce maintenance, but each new service adds configuration, cost and knowledge requirements. A small application does not become safer because its diagram contains more boxes. The strongest design is the simplest one that meets the workload, security, recovery and growth needs.

06

Make the application safe to run away from one server

Many older applications work because one server remembers more than anybody realised.

User sessions may be stored on its disk. Uploaded files may sit beside the application code. A scheduled task may run because somebody added it manually years ago. A queue worker may only restart when the whole machine reboots. Configuration can depend on a hardcoded path, hostname or IP address.

Those assumptions matter when the application runs on more than one instance or an instance is replaced.

Move durable files to suitable shared or object storage. Put sessions and cache data where every application instance can reach them. Define scheduled jobs and workers as part of the deployment. Move secrets out of the code and server history. Make configuration explicit. Confirm that two copies of the same scheduled process cannot accidentally send two invoices or import the same order twice.

Containers can help package a runtime consistently, but they are not the objective. A repeatable, observable application is the objective. If a straightforward deployment to a managed platform achieves that, adding containers purely to make the migration sound modern may create work without reducing risk.

07

Prove the new environment before cutover

A green health check only proves that one endpoint answered.

Build the new environment using a repeatable process. Load a realistic copy of the data with the right privacy controls. Test the journeys the business depends on: sign in, search, create an order, upload a document, take payment, send an email, run an import, complete a scheduled task and produce the reports people use at the end of the month.

Test each user role. Check third party callbacks and allowlists. Confirm certificates, DNS settings and outbound email. Run the application at realistic and peak load, then compare the result with the baseline.

Recovery deserves its own test. Restore a backup into a separate environment. Prove the restored application can start and that the data is usable. Exercise the failure of a worker, an instance or an external service. Confirm that the right person receives an alert containing enough information to act.

AWS guidance separates migration into assess, mobilise and migrate phases. That sequence is useful even for a single application. Understand the estate, prepare the foundations and people, then move using a tested method. Skipping the middle phase is how an apparently quick migration becomes a long incident.

08

Write the cutover runbook

The cutover should be a written sequence, not a collection of messages sent during the maintenance window.

Give each task an owner, an expected duration, evidence of completion and a decision if it fails. Include the change freeze, final backup, data synchronisation, application stop and start, routing or DNS change, smoke tests, business acceptance, monitoring checks and user communication.

Define the point of no return. State who can approve the cutover, who can call a rollback and who communicates with users. Record supplier contacts and access methods before the window begins.

For our wholesaler, a useful sequence might be:

• Freeze application changes and confirm the tested release.
• Confirm backups, restore evidence and the current rollback target.
• Stop writes or place the old application into maintenance mode.
• Run the final database and file synchronisation.
• Start the AWS environment and switch routing.
• Test login, ordering, payment, email, uploads, imports and reporting.
• Ask the business owner to accept or reject the service.
• Monitor the agreed measures and keep the migration team available.

DNS time to live values, certificate issuance, firewall rules and external allowlists should be prepared before this list begins. A cutover window is a poor time to discover that a supplier only updates an approved IP address during office hours.

09

Rollback stops being simple when new data arrives

Before users write new data to the AWS environment, rollback may be little more than switching traffic back. After new orders, uploads or payments arrive, the old database is stale.

That changes the decision. A rollback may now require data reconciliation, a reverse synchronisation or a period of manual handling. For some failures it is safer to fix the new environment and continue forward. For others, stopping the service and restoring the previous environment is still the right call.

Define rollback thresholds before cutover. They might include an unacceptable error rate, failure of a critical journey, data inconsistency or performance below the agreed minimum. Set the time by which the decision must be made. Name the decision owner. Write what happens to data created after the switch.

A rollback plan that says point DNS back is incomplete.

10

Watch the first hours and days

The first successful order is not the end of the migration.

Watch application errors, response time, database load, queue depth, scheduled job completion, storage, email delivery and cloud spend. Compare them with the baseline and the acceptance thresholds. Ask support and operations what users are reporting. A technical dashboard will not reveal that a printable document is missing a field somebody needs at 4pm.

Keep a defined period of closer support. Record any workaround or manual change made during cutover, then move it into the repeatable configuration or deployment process. Review permissions created for the migration and remove temporary access.

Do not switch off the old hosting on launch night. Preserve the agreed backup, snapshot, logs and configuration. Keep the old environment isolated or read only for the planned assurance period. Then confirm retention needs, contracts and access before decommissioning it.

Leaving it running forever is not safer. It creates a second bill, another unpatched environment and uncertainty about which copy of the data matters.

11

Migration is finished when the business can operate it

The wholesaler does not need a clever AWS diagram. It needs a portal that survives its busy period, a deployment the team can repeat, a recovery process somebody has tested and clear ownership when an alert arrives.

The handover should include the architecture, deployment steps, access owners, monitoring, backup and restore process, known limitations, supplier dependencies, expected costs and the next sensible improvements. Schedule reviews for cost, capacity, recovery and security rather than assuming the first design will remain right forever.

If your application is sitting on inherited hosting and the move to AWS feels larger every time somebody looks closely, I can help map the workload, choose a proportionate route and turn the migration into a controlled sequence of decisions.