Online Player Services and Backends: Migration Help Sheet
Games exist today for longer than ever. Built with a few years of lifetime in mind, many are still around long beyond their life expectancy. However, the backend tech has remained the same throughout – and that’s a problem, because what was built for a short run isn’t designed to last long-term. Whether it’s bespoke and technical debt has taken hold, or it’s a platform that’s now legacy or even starting to close shop, there are things you can do to move your game somewhere new – where it can thrive indefinitely.
Common symptoms: Tackling the fundamental issues
We often hear the following:
“We want to add a feature but we’re scared we’ll break something else”
“Nobody knows how this stuff works anymore”
“My online player services platform provider is a risk now”
“This backend was fine years ago, but it just won’t scale for what we need today”
If you operate a game in this space, you’ve likely uttered one or several of these yourself.
Migration strategies
In many cases, it’s sufficient to just dust things off and clean up the code, but often it’s worth taking a real look under the hood (bonnet for us Brits) and getting a plan together for the future.
At Code Wizards, we largely work to one of two scenarios:
- The backend system is supported and current
- The backend system is no longer supported (or badly supported) so we look to move the title to a new platform
We find the best way to discover if it’s the first or second is a simple assessment project.
Assessment projects vary in length, but the purpose is to establish:
- The current situation
- Is the current platform viable?
- Is the current code base updatable?
- If we were to move the game, what are the best platforms to migrate to?
- Is there potential for funding from a partner to help the migration?
We know that game teams are always super busy, so most of this work our team can and often does without interrupting what your team is up to.
An example of a successful migration
While we can’t name games due to client privacy, let’s look at a real-life migration we completed, moving the title from a heavily customised legacy backend platform to Heroic Lab’s Nakama server running in Heroic Cloud.
The game was handling reasonable levels of CCU, circa 150K mean average with a peak of 180K during the normal U.S. day. It had already been running for five years and had a lot of data that wasn’t being used. The team were concerned that the game would go offline and downtime was already starting to occur due to faults.
We first looked at the existing platform; the way it was integrated into the game client, what data was being passed back and forth, and the code that was being run.
We then categorised this by functional areas. Here’s an example of what that looks like in practice:
| Area | Sub-Area | Simplex or Duplex | Custom Code or Vanilla | Custom Code Language and Version |
| Currency | Fiat Currency | Duplex | Custom (3K lines) | Lua |
| Currency | Soft Currency | Duplex | Custom (0.2K lines) | Lua |
| Matchmaker | 1v1 Matchmaking | Simplex | Custom (20 lines) | YAML |
Once complete, we understood the functional areas that needed addressing, and where deep customisation had occurred (meaning that there was plenty of hidden functionality in there).
We then mapped that to other systems and estimated the cost AND benefits of moving. In this case, a major bonus was that the 1v1 Matchmaker could be massively improved, as it didn’t originally allow for things like location or skill level.
A plan was devised where each section would be re-implemented and automated tests built for before-and-after functionality. This also included load and soak testing for the proposed Nakama environment, and how to modify the game client to use the new system.
Once complete, this was shown to the game’s senior team, showing the risks, rewards, and how we proposed to handle each area.
After a productive meeting with concerns raised and solved, we were given the green light to proceed. It’s important to call out that a major risk mitigation for this team was that Nakama offers an open-source version which can be used in future, if the hosted service shuts down.
How did it go?
Data was mapped and a trial run took the live service and pushed it over to Nakama into its PostgreSQL database (ideal for migrations as source data can be retained after migration for audit and detecting bad data migration issues in future, should they occur).
Code was rewritten in Golang to be massively efficient, and automated tests were added so we could be sure that we were matching current functionality. We also enhanced the matchmaker to include location, skill level, and to automatically widen the matchmaker quickly when perfect matches for players couldn’t be found.
Load testing showed several issues in the inventory system which were soon managed by optimising the calls.
In just 4 months the team took the project from concept to final delivery.
And the result? A studio with faster running, cheaper backend services, a future proof strategy, and happier players!
Tips for those looking to Migrate
Thinking of migrating yourself? Whether you plan to go it alone, or are thinking of reaching out, here are some tips to consider as you go forward:
Plan hard! It may seem easier to wade in and get started but ideally your planning stage should include in-depth analysis, collaboration between multiple team members, one-eye on your future roadmap, and time spent identifying risks.
Apples aren’t oranges. Every system has capabilities, features, and quirks so it’s unlikely that there’s an easy 1-to-1 mapping. Even if there is, don’t assume the two systems perform the same.
Migrate “lift-and-shift” style while understanding which bits to improve or replace. Attempting to improve everything while migrating is really a rewrite of the backend and likely the game client too. Make life easier by identifying the best bits to upgrade and do those, then create a plan to go back and improve elsewhere over time once you’re safely on the new system.
Finally, look at the destination system carefully. It’s easy to look at features, how shiny it is, or who is using it, but the boring elements are just as important. What languages does it support? If you double your CCU / DAU will it handle it? What happens if the supplier ever stops developing, pivots to something new, or Chapter 11s? Does that supplier have good support?
As always, our door is always open if you’d like to chat to someone about your current configuration and whether a move makes sense for your game.
About Code Wizards Group
Code Wizards Group is a leading gaming technology partner specialising in cloud-native game development, AI-powered tools, and scalable multiplayer infrastructure. With deep expertise in AWS services and a track record of helping UK studios ship successful titles, Code Wizards combines technical excellence with practical, commercial understanding of the gaming business.