Logo

Migrating your community from Garry's Mod to S&Box

Migrating your community from Garry's Mod to S&Box

Strategic and technical guide: what translates from GMod to S&Box, what changes radically (Lua → C#, Workshop → sbox.game, server.cfg → CLI), and how to migrate your community without losing it.

Introduction

S&Box is officially Garry's Mod's spiritual successor. On paper that's reassuring, but in practice almost nothing is compatible: new engine (Source 2), new language (C# .NET 9), new distribution platform (sbox.game), new architecture (Scene-based instead of Entity-based). This guide helps you plan the transition on both server and community sides.

Prerequisites

  • An active GMod community or migration project
  • An S&Box server (at VeryCloud, ideally in parallel of your GMod during transition)
  • Time: depending on gamemode complexity, several weeks to several months of porting

Step 1: Inventory of existing GMod

Before migrating, take stock of your current GMod server:

GMod elementMigration action
Custom Lua gamemodeRewrite in C# (no auto-port)
Workshop addonsFind equivalents on sbox.game or build
.bsp mapsConvert / rebuild in S&Box Hammer
server.cfg ConVarsMost no longer exist
MySQL DB (MySQLOO, etc.)Reusable as-is (.NET driver)
ULX/ULibRebuild via S&Box claims system
FastDL HTTPNo longer needed (sbox.game cloud)

Step 2: What does NOT translate

Lua → C#: no reliable automatic conversion tool. Gameplay code must be fully rewritten. Same logic (events, hooks, entities) but API changes.

Workshop → sbox.game: different system. You don't recover your workshop addons, you replace them.

net.Send / net.Receive[Rpc.Broadcast], [Rpc.Owner], [Rpc.Host] in C#.

hook.Add("PlayerSay", ...) → event patterns / overrides in C# Components.

SENT/SWEP entities → Components attached to GameObjects (Scene architecture).

Step 3: What translates well

Concepts: players, teams, scores, inventories, economy — all of it exists in some form.

Databases: your MySQL/MariaDB schema remains valid. Just swap the Lua driver (MySQLOO/tmysql) for a .NET driver (MySqlConnector for example).

Admin knowledge: bind, scoring, moderation, ban/kick, community rules — all still relevant.

Discord webhook, external integrations: equivalent .NET code, just another language.

Step 4: Server-side migration plan

Phase 1 — Parallel setup (week 1)

  1. Order an S&Box server at VeryCloud (SboxDev or Plus depending on target)
  2. Configure the Wisp panel as described in the "Getting started" tutorial
  3. Load facepunch.sandbox to test
  4. Officially announce to your community the migration project

Phase 2 — Gamemode porting (weeks 2-N)

  1. Install S&Box dev tools (integrated editor + Rider/VS)
  2. Create a new .sbproj
  3. Rewrite critical systems first: login, save, economy
  4. Test locally before deploying

Phase 3 — Closed beta (1-2 weeks)

  1. Upload the .sbproj to your S&Box server (or private publish on sbox.game)
  2. Invite admins and trusted players
  3. Identify bugs and feature gaps vs GMod

Phase 4 — Official migration

  1. Announce the date 2-3 weeks ahead
  2. Keep GMod running in parallel 1 month after S&Box opens (retention)
  3. Transfer player data if relevant (MySQL exports → import into new schema)

Step 5: Migrate player data

If you have a MySQL DB on the GMod side with player progression/stats, you can migrate to your new S&Box schema.

Example simple pipeline:

# Export GMod
mysqldump -u user -p gmod_db players > gmod_players.sql

# Adapt the schema (manual SQL script to write)
# - IDs: Steam ID 32 -> Steam ID 64
# - New S&Box gamemode fields

# Import S&Box
mysql -u user -p sbox_db < adapted_players.sql

In the S&Box gamemode, read this table as you'd read any DB from C#.

Step 6: Communicate to your community

The most important. Without communication, you lose players.

Announce clearly:

  • Why you're migrating (Source 2 perfs, GMod end-of-life, new features)
  • Exactly when the switch happens
  • What's preserved (ranks, virtual currency, etc.)
  • What's reset/lost
  • How players install S&Box (Steam, ~€20 at launch)

Discord, pinned post, recap video. Don't underestimate the need for education.

Step 7: Keep GMod in parallel

Until your community is 80%+ migrated, keep the GMod server active. Coexistence of both for 1-2 months gives you:

  • A fallback if S&Box hits issues
  • Time for late players to buy S&Box
  • Opportunity to compare live

At VeryCloud, you can run both side by side on the same account.

Troubleshooting

"Players don't want to buy S&Box"

  • Unavoidable for some. Communicate the new server's value
  • Keep GMod longer than planned if the base doesn't migrate

"My Lua code is so custom it's unmanageable to port"

  • Rewrite critical systems in C# and accept losing secondary features
  • Consider it a chance to pay off technical debt

"S&Box performs worse than GMod"

  • Source 2 demands more hardware. Scale up VeryCloud plan
  • Profile your C# code (see S&Box perf tutorial)

Useful commands

# Export GMod MySQL
mysqldump -u user -p --single-transaction db_gmod > backup.sql

# Compare two schemas (mysqldiff)
mysqldiff --server1=user@gmod_host:port --server2=user@sbox_host:port

# Test DB connection from your .sbproj in C# (excerpt)
# using MySqlConnector;
# var conn = new MySqlConnection(connStr);

Conclusion

Migrating from GMod to S&Box isn't an upgrade, it's a rebuild. Code is rewritten, addons replaced, maps rebuilt. But Source 2 + .NET 9 + asset.party give you a technical base 10 years more modern, and it's the chance to rethink your server without accumulated debt. Plan seriously, communicate with your community, and keep GMod in parallel during transition.

Going further: advanced porting of GMod hooks to C# patterns, monetization and Steam compliance, gamemode-side observability.

Resources

Join our Discord community server

For any questions, suggestions, or just to chat with the community, join us on Discord!

900+Members