What I walked into
SPSG was moving from an older .NET/MySQL system to a new NestJS/PostgreSQL application. I was the engineer focused on mapping and moving the legacy data into the new schema.
Legacy platform migration
SPSG
Mapped and migrated an entire legacy MySQL data model into a new NestJS/PostgreSQL platform, covering roughly 23,000 users plus related records.
SPSG
23K+users in the legacy dataset
MySQL→︎Postgresdatabase transition
table-by-tablecontrolled migration
What had to be solved
The schemas did not match one-for-one, and legacy records did not always satisfy the validation rules of the new application. The migration needed to preserve as much data as possible without silently hiding failures.
My contribution
THE WORK I OWNED
01
Mapped the old schema to the new model and wrote migration scripts in the new TypeScript/NestJS system that connected directly to the legacy MySQL database.
02
Migrated the database table by table, covering roughly 23,000 users plus the wider set of related records rather than only the user table.
03
Used transactions and rollback behavior where a record needed all-or-nothing validation.
04
For records that could not satisfy the new validation rules, skipped them deliberately and kept a history of what failed and how many records completed.
05
Ran and verified the migration in development environments before handoff/cutover work continued.
System view
HOW THE PIECES CONNECT
01Legacy .NET app
02MySQL
03Migration scripts
04Validation / transactions
05NestJS
06PostgreSQL
Outcome
The migration scripts gave the team a repeatable path from the legacy MySQL model into PostgreSQL while keeping validation failures visible instead of losing them silently.
Technology
TypeScriptNode.jsNestJSPostgreSQLTypeORMMySQL.NET legacy source