We migrated a team from Unity to Godot - not as beginners, but as experts whose Unity instincts actively worked against us. The habits that made us fast in Unity quietly produced brittle, un-idiomatic Godot code, and the bill came due within weeks.
This is the honest post-mortem of our first month: the mental models that collided, the muscle memory that backfired, and the day source control broke. For each, we’ll show what we assumed, what actually happened, and the convention that fixed it - so your first month is shorter and less painful than ours.
Most “switching to Godot” talks target newcomers. This one is for teams who already know how to ship - because migrating experienced engineers is a different, harder problem. Your expertise doesn’t transfer cleanly; it misleads you. Godot looks enough like Unity that you reach for familiar patterns, and those patterns are exactly what produce fragile code.
We’ll walk through the specific collisions our team hit, in three buckets:
Mental models that don’t map 1:1:
- GameObjects-and-Components vs. nodes-and-scenes
- Prefabs and variants vs. PackedScenes and scene inheritance (where instancing and overrides genuinely differ)
- ScriptableObjects as Data Containers vs. Resources
Update()vs._process/_physics_process.
Muscle memory that backfired:
- Porting Unity’s singleton/manager soup straight onto autoloads
- The
GetComponent<>()reflex becomingget_node()coupling - And the big one, “we already know C#, so we’ll just use C#”. The honest team tradeoff between GDScript and C# (iteration speed, export pipeline, community examples).
The day git broke:
- Scene and resource files are text now: diffable, but conflict-prone.
- How we kept scenes small and reviewable
- what to commit vs. ignore
We’re just one team, one project into Godot - so this is what worked for us, not a definitive playbook. But if sharing our wrong turns spares you a little of the trouble they cost us, that’s a win.
Audience: engineers, tech leads, and studio decision-makers considering or mid-migration.