Loading page
A migration is a data problem wearing a version number. The code is the visible half; the half that decides whether the weekend goes well is whether the data lands intact, and whether you can go back if it does not.
The business problem
You are two or three versions behind, security patches have stopped, and every quote for moving forward comes with a shrug about the customisations.
The risk is not the upgrade script. It is the custom module nobody has read since it was written, and the assumption that a rollback exists.
What we build
Every custom module read and classified: port, rewrite, or drop. You get that list before anything is quoted.
The migration is performed on a copy, end to end, and the result is used by your people before the real one is scheduled.
Row counts, balances and open documents reconciled between the two databases and signed off.
Written down, timed, and proven on the rehearsal - not a paragraph in a plan.
Reference architecture
Boring on purpose: one API surface, one source of truth per concept, integrations at the edge, and an audit trail from day one. Diagrams are produced per project and included in the handover pack.
Related
FAQ
The assessment is quick. The rest depends almost entirely on how much custom code there is and how it was written, which is exactly what the assessment tells you - so we scope after it, not before.
Usually. Some are cheaper to rewrite than to port, and the assessment says which is which, with the reasoning.
Backed up before anything runs, reconciled after, and never migrated in place on a production database without a rehearsal first.
A short paid discovery: we map the process, agree the architecture and produce a scoped plan you own regardless of who builds it.
Fixed for discovery and clearly bounded phases. Time and materials for ongoing product development, with a monthly cap.
You do, from the first commit, in your own repository.