31 August 2026 · 8 min read

How do you move a live platform to a new server safely?

Most maintenance work is forgiving. A server move on a platform holding user balances is not, because the failure mode is not downtime. It is two copies of the truth.

Why does a move need a plan?

Because for a period, two machines can both believe they are the platform. If both accept a deposit, or both run the payout scheduler, you now have two versions of every balance and no clean way to merge them.

Downtime is the cheap problem. Divergence is the expensive one, and it is silent.

What to do before you touch anything

1. Take a backup and verify it restores somewhere else. An untested backup is a hope
2. Write down the current version and configuration, including scheduler settings
3. Note your current totals: users, active plans, outstanding liability
4. Pick a quiet window and tell users, with a start and end time
5. Build the new server and install the platform there, without pointing the domain at it

Step three is the one people skip. Those figures are how you prove afterwards that nothing was lost, and they come from the screen described in outstanding liability, the number most operators never watch.

The order that cannot lose money

The rule underneath the sequence is simple: only one machine may be live at any moment, and only one scheduler may ever be running.

The duplicate scheduler trap

This is the mistake worth naming on its own, because it is common and it is quiet.

You move the platform, everything works, and the old server is left running for a few days as insurance. Its scheduler is still configured, still pointing at a database, and still running accruals. If both point at the same database, every user is credited twice a day.

Nothing errors. The site looks healthy. What you owe grows twice as fast as it should, and you discover it when the numbers stop making sense. The scheduler itself is explained in what actually runs your payouts?

What to check afterwards

• Your three totals match what you noted before the move
• A test deposit credits correctly on the new server
• A test withdrawal appears in the queue and can be approved
• One accrual cycle runs, once, at the right time
• Emails still arrive, since sending configuration often lives on the server
• The old scheduler is definitely stopped, verified rather than assumed

Emails are the item most often broken by a move, and it is silent until a user says they never received a withdrawal confirmation. See the platform email guide.

Knowing when to roll back

Decide before you start what would make you abandon the move: totals that do not match, a failed test deposit, a scheduler that will not run.

Rolling back is easy while the old server is intact and nothing new has been written to the new one. It becomes hard the moment real users have transacted on the new install. That is why verification happens before the domain moves, not after.

Common questions

Question this did not answer? Ask on Telegram. Reader questions get written up first.