In an acquisition, the system question is settled before the project begins: the group system wins, the data has to go in, the deadline stands. Whether the target system is functionally superior to the old one does not matter. What decides success or failure is discipline in execution.
The constellations look alike: a group acquires a mid-sized company, a business unit is carved out, several entities get consolidated after a series of deals. So does the pattern behind them: undocumented legacy systems, incompatible cost accounting, a date that is not negotiable. That is exactly what my ERP migration approach is built for.
Undocumented legacy systems
In grown mid-sized companies, system documentation is rarely complete. Discovery then runs as reverse engineering: interfaces, custom fields and manually maintained tables are traced and documented one by one. That is how the integration of an acquired consulting firm (80 employees) into a group landscape worked: undocumented legacy, cut-over in a single weekend, business running on Monday, no rollback (case study).
Harmonizing cost accounting
M&A integrations rarely fail at the mechanics of data transfer; they fail at incompatible data models. In the case above, two different cost accounting models had to be moved into the group logic: a mapping task, not a configuration question. A pharma company (250 employees) faced the same task without an acquisition, across divisions grown apart with separate systems: three legacy systems with different data structures, and finance needed a central reporting structure. The consolidation onto one SAP system went live on schedule in two waves.
One weekend or two waves
Big bang over a weekend or a staged go-live follows from the constellation, not from preference. Both routes need the same foundation: discovery, field-by-field mapping, test runs against real data, defined acceptance criteria. How this played out in the M&A case is in my article on the M&A cut-over.