Leading migrations end to end, then automating the processes the migration exposed as manual.
An ERP migration is judged on one day. Either the business can invoice on Monday or it cannot, and there is no partial credit.
That shapes everything upstream: the mapping has to be reconciled rather than plausible, the cutover has to be rehearsed rather than planned, and the rollback has to be defined and tested before anybody agrees to a date.
Field mapping is laborious and it is tractable: you can count records, reconcile totals and prove a table arrived intact. What is not written down anywhere is the business rules. The discount that one person applies from memory. The status that means something different in one department. The report that is correct only because of a workaround nobody documented.
Migration is where those surface, because the new system refuses to accept them. Most of the real work of a migration is finding them and deciding, with the business, which are rules worth keeping and which were always mistakes.
A rehearsed cutover is one that has been run against real data, timed, and failed at least once in rehearsal so the failure mode is known. A rollback is only real if somebody has executed it.
Both exist to make the go-live decision a technical one rather than an act of faith on the night.
A migration produces an unusually honest inventory of manual work, because every manual step had to be described in order to be moved. That inventory is where automation should start, and it is the reason the automation phase belongs to the same programme rather than to a later project that has forgotten what was learned.
The system, the vendor, the organisation, the data model or the volumes. Described at a high level under NDA.
Work carried out under NDA. This page describes the engineering, not the employer. No employer names, internal architectures, client details or proprietary systems appear anywhere on this site, and none will be added.