An aging ERP (enterprise resource planning system) is like a company's heart. Orders, inventory and settlement run on it every day, so even when it's old you can't just stop it for a day and rebuild. Here are the principles and order we set for the PHP 5.5 ERP migration SOL LABS is currently working on.
1. Move screen by screen, not all at once
The most important principle is no big-bang cutover. If you build the whole new system and switch over in a single day, every business rule you missed blows up on that same day.
Instead, we leave the existing system running and move one screen (menu) at a time to the new architecture. Users keep using the same menus, while behind the scenes some screens are served by the new system and others by the old one — on purpose. Developers call this the "strangler pattern": wrapping the old system and replacing it piece by piece.
- Start with frequently used but simple lookup screens
- Move screens that touch money or inventory only after verification is in place
- Compare every migrated screen's results side by side with the old one
2. The new architecture: screens in Next.js, business rules in Spring
The new architecture splits responsibilities in two.
| Layer | Technology | Responsibility |
|---|---|---|
| Screens | Next.js · TypeScript | Fast screens, role-based menus, mobile support |
| Business rules & data | Spring | Order, inventory and settlement calculations, transactions, permission checks |
| AI features | Separate service | Document summaries, search, connection to in-house AI |
In the PHP days, SQL and calculation logic were often mixed into screen files. During the move we gathered all calculations into Spring, which also fixed the problem of the same rule being copied across several screens.
3. Data migration starts with a mapping table
Before writing code for the database migration, we build a mapping table: where each old table and column goes in the new schema and how values change. Migration and verification scripts are both built from this table.
Row counts (before and after), totals (sums of amounts and quantities) and samples (a few random records compared on screen) — all three must match before moving to the next step.
4. Redesign permissions
The longer a system has been used, the more "please let this person see that menu too" exceptions pile up, and permissions get tangled. Move them as-is and the tangle moves too. So we redefined roles around actual job functions and switched to granting permissions to roles rather than to individuals.
5. Make room for AI during the move
A migration is also a great chance to add AI. Once data is clean and business rules live in one place, you can connect a language model on the company's own server to answer questions like "summarize this month's customers with outstanding receivables." This project is building an in-house AI server alongside the migration.
In short: for systems that can't stop, move in small pieces, compare every time, and keep the rules in one place.
We review your current system and data, then outline the migration order and scope.
We build web apps, mobile apps and business systems, then add and run the AI they need. We build and operate our own meeting notes, contract and company analysis AI.
See our projects