[Proposal] EU1 / EU3 merge: why it's feasible, and how we can help

Discussion in 'Update & Idea Pool' started by fantomas_, Sep 2, 2026 at 11:21 PM.

Dear forum reader,

if you’d like to actively participate on the forum by joining discussions or starting your own threads or topics, please log into the game first. If you do not have a game account, you will need to register for one. We look forward to your next visit! CLICK HERE
  1. fantomas_

    fantomas_ User

    I know this topic keeps coming back, and every time the conclusion has been "technically impossible." I'd like to revisit it with an actual concrete plan, because merging MMO game databases isn't unprecedented — other studios (including Bigpoint on other titles, and plenty of browser-game publishers) have done it before. It's not simple, but "hard" and "impossible" aren't the same thing.
    1. Technical audit — the step that proves it's possible
    This is the starting point, and it directly answers the "it's impossible" objection: before saying a merge can't be done, you first need to know what's actually in the databases.
    The audit should cover:
    • Database structure (accounts, IDs, ships, equipment, currencies, inventories)
    • Guilds, rankings, purchase history, quests, sanctions
    • Data format: are EU1 and EU3 compatible, or does data need converting?
    • Technical dependencies: game engine, server version, any code differences between the two servers
    • Actual data volume to migrate (number of active accounts, database size)
    Without this audit, you can't say "it's impossible" — you can only say "we don't know." And that's exactly what's been missing from previous discussions: they ended in a conclusion without an audit ever being done or shared publicly. If Bigpoint has already done this audit internally and found it to be a blocker, it would help if they shared the specific technical reasons — that would let us move forward on facts instead of a general conclusion.
    2. Dedicated test server
    Never touch the live servers directly. Create a test copy: EU1_TEST + EU3_TEST → EU_MERGE_TEST, to validate the merge without any risk to real data.
    3. Data migration
    New European database, new IDs, and a mapping table linking old IDs to new ones. What gets preserved: progress, ships, equipment, inventory, currencies, quests, achievements, guilds, purchases, rewards.
    4. PvP and guild testing
    Maps, combat, guild wars, matchmaking, events, server load — all tested before launch.
    5. Cutover plan (example)
    02:00 close EU1/EU3 → 02:15 full backup → 02:30 last sync → 03:00 migration → 05:00 checks → 07:00 final tests → 08:00 reopening. The old databases stay archived so it's possible to roll back if something goes wrong.
    6. Gradual rollout
    Internal tests → 10% → 50% → 100%, with heavy monitoring for bugs, payments, and economy issues.
    7. Turning it into a real relaunch
    New server, new PvP leaderboard, merge-themed events, rewards, guild competitions, and outreach to former players to bring them back.
    8. Handling duplicates
    Identical usernames across servers (e.g. BlackPearl_EU1 / BlackPearl_EU3) → offer the player a rename. Same logic for guild names. For accounts that exist on both servers, define a clear rule (merge accounts, or keep both profiles separate).
    9. Securing the economy
    Preventing any duplication of diamonds, gold, resources, or items. Automated checks before and after migration to compare totals.
    10. New leaderboard
    A unified European leaderboard instead of just adding EU1 + EU3 together, with the old rankings archived as history.
    On cost: I obviously can't give a reliable figure without access to the actual code and infrastructure — but this kind of operation is usually budgeted in the tens of thousands of euros, not millions, assuming the source code is still available.
    The real risk isn't creating the new server — it's migrating years of data without breaking player progress or the in-game economy. That's manageable with a proper audit and testing phase — which is exactly why step 1 gets top billing here.
    We're ready to help. Several players have already volunteered for a community audit, testing, or even technical support if the Bigpoint team is short on resources for this project. If the moderators or dev team want us to formalize this (volunteer list, available skills), we're in.
    Thanks for reading this far — hopefully we can restart this discussion on concrete grounds instead of it being dismissed as "impossible" without a detailed audit having been done or shared.