How do you move a long-running live game's backend to the cloud without downtime?

Games that have been live for ten or fifteen years often run on backends built for a different era. They may sit on hardware in a data center the studio has leased for years, rely on services nobody has touched since the engineers who wrote them moved on, and keep most of their state in one large database. They also still have players who log in every day and expect the game to be there.

Moving a backend like that to the cloud is very achievable, and players do not need to notice it happening. The work has to be done in planned stages, with a way back at every step. This is how we approach it.

Why are older game backends hard to migrate?

The difficulty is rarely the cloud itself. It is usually the things the backend has picked up over the years:

• Services that depend on each other in ways nobody has written down
• Hard-coded server addresses, file paths and hardware assumptions
• A single database that every service reads and writes
• Test suites that only run against the old environment, if they exist at all
• Scheduled jobs, scripts and manual processes that keep things running in the background

Each of these can break a migration that looks simple on paper, so the first stage is finding them.

What are the stages of a live game cloud migration?

1. Assess the current system

Map every service, database, job and external dependency, along with what each one costs to run today. Talk to the people who keep the game running, because a lot of the important knowledge is in their heads. This stage also shows which parts carry the most risk, which helps decide the order of the move.

2. Agree the migration order

Plan the order with the studio, working around live events, seasons and platform deadlines. Stateless services, such as web front ends and API layers, usually move first because they are easy to run in two places at once. Databases and anything holding player state usually move last.

3. Build the testing you will rely on

Before moving anything, make sure you can test it. For one client we built a load testing platform that simulates more than 10 million concurrent users and kept all of their existing tests, 20 years of them, working on the new platform. Old tests carry knowledge about edge cases that would be very hard to rebuild, so keeping them is worth the effort.

4. Move services in stages

Run each service in the cloud alongside the original, send a small share of traffic to the new version, and increase it as confidence grows. If something looks wrong, traffic goes back to the original while the problem is fixed. Players see the same game throughout.

5. Migrate the data

Player data needs the most care. A common pattern is to replicate the database to the cloud continuously, check that both copies match, then switch writes over in a short, planned window at a quiet time for your player base. With good preparation that window can be short enough that players do not notice.

6. Retire the old environment and review costs

Once everything runs in the cloud and has been stable for a while, the old hardware and contracts can go. This is also a good time to look at what the new setup costs. Lifting old systems into the cloud without resizing them can cost more than expected, and a cost review at this point usually finds savings.

How long does it take to migrate a game backend to the cloud?

It depends on the size of the backend and how much needs to change along the way. A focused migration can be quick. We moved a simulation platform's five components to AWS GovCloud IL5 in seven weeks to meet a contract deadline. A large, long-running game backend with many services and a lot of player data will usually take a number of months, split into stages so the game keeps running throughout.

How Terminal Velocity helps with legacy and cloud modernization

Terminal Velocity moves important systems that are 10 to 20 years old onto modern cloud infrastructure, in stages, so your product stays available throughout. Our work covers assessment and planning, migration to AWS and other providers, including regulated environments such as AWS GovCloud, and infrastructure cost reviews. In one six-week audit, we cut a client's infrastructure bill from $500K a month to $250K a month.

If you are planning a move for a game that has been live for years, see our legacy and cloud modernization work or plan your migration with us.

Frequently asked questions

Will our game go offline during the migration?

It should not need to. Services move in stages and run in both places for a time, and the final data switch happens in a short, planned window at a quiet time for your players.

Which cloud providers does Terminal Velocity migrate to?

We migrate workloads to AWS and other cloud providers, including regulated environments such as AWS GovCloud.

Can moving to the cloud reduce our hosting costs?

It can, especially if the move includes resizing services and removing waste. A cost review is part of how we plan and finish a migration.

What happens to our existing tests?

We keep them. On one project we preserved 20 years of existing tests on a new load testing platform that simulates more than 10 million concurrent users.