The Deal Closed. Now NetSuite Has to Absorb the Company.
The day a deal closes brings a press release, a few handshakes, and a lot of relieved people. The day after, a different question lands on my desk. The company we just bought runs on a system nobody on our side has ever logged into, and everything it does, every item it stocks, every load it bills, every document it trades with partners, now has to end up in NetSuite. Nobody sends flowers when that goes well. If I do my job right, the only sign it happened is that the numbers keep showing up.
This is what that job looked like when we absorbed an acquired fuel distributor running on ADD Systems’ E3, an ERP built for fuel and energy distributors. The deal strategy was somebody else’s job. Mine was the part where a warehouse, a lubricants operation with its own manufacturing, on-site and terminal fuel sales, and a stack of EDI trading partners all had to become part of one NetSuite account while the business kept selling.
The risk is not the software
People picture post-merger integration as a technical migration, and it is one. The danger lives somewhere else. It is a Tuesday where a fuel load leaves the rack and nobody can bill it because the customer record exists in two systems and neither one is sure which is real. It is an EDI partner receiving a document that no longer parses because a mapping changed and nobody told them. It is a warehouse crew that cannot receive a shipment because the item numbers on the truck do not match the item numbers on the screen.
Every one of those is a cash problem and a trust problem before it is an IT problem. An acquisition is already a period where customers, vendors, and employees are watching for reasons to worry. The systems work has one job, which is to give them none.
Day 1 is a decision, not a date
The single most useful thing I did was refuse to treat the migration as one event. Each part of the acquired business got its own cutover, and each cutover got a hard line between what had to work the morning after and what could wait. Here is how that line fell.
| Had to work on Day 1 | Could wait |
|---|---|
| Receiving, picking, and counting in the warehouse | Historical transaction detail beyond opening balances |
| Manufacturing work orders consuming components | Reporting polish and dashboards |
| Fuel order-to-invoice, so loads could be billed | Legacy customizations that existed because E3 required them |
| EDI documents flowing to and from trading partners | Nice-to-have automations that were not on the critical path |
| Opening inventory and open orders reconciled | Cleanup of records that had been dead in E3 for years |
Everything in the right column was real work people wanted. It just could not cost us an invoice, so it did not ride along on cutover weekend.
The waves, in order
We moved the lubricants warehouse and its manufacturing first, as one wave, because physical inventory is the truth everything else depends on. If receiving and work orders are wrong, every downstream number is wrong, so that had to be solid before anything touched revenue. The EDI trading-partner flows came after, and deliberately so. EDI is the one piece where a mistake is immediately visible to someone outside the company, so it went last, once the item and customer data underneath it had already proven itself in production. The fuel sales flows had their own cutover on their own schedule, with the same rule: bill correctly on the first day or do not switch yet.
The whole sequence ran a few months, in waves. Each wave had its own Day 1, reconciliation, and go or no-go decision. That sounds slower. In practice it is the fastest way to move a company, because a wave that fails is small enough to fix and a wave that succeeds builds the confidence to run the next one.
Where NetSuite makes you decide things
An acquisition forces choices that a normal implementation lets you dodge. The ones that mattered most here:
- The item master. This was the ugliest data in the whole program. The acquired company had its own item numbers, units of measure, and pricing logic, many thousands of item records in all, and every one had to land in a NetSuite item master that already had opinions. Duplicate items, base unit versus sale unit mismatches, and price lists that meant different things in different systems are where post-merger integrations break. I owned that cleanup myself rather than handing it to a vendor, because whoever owns the item master owns whether the first invoice is right.
- Chart of accounts and subsidiaries. Two businesses means two ways of booking the same thing. Deciding whether the acquired operation lives as its own subsidiary or folds into an existing one, and mapping every one of its accounts to ours, has to happen before a single transaction migrates.
- Customers, vendors, and trading-partner IDs. The same customer can exist on both sides with different terms, different tax setup, and different EDI identifiers. Merge them wrong and you bill the right company at the wrong price.
- Permissions and roles. New people, new locations, and new approval paths. Getting this wrong does not break the system. It breaks the people using it on their first day.
- Integrations. Every EDI map and every connector, ours ran through Boomi, had to be re-pointed or rebuilt, then tested with real partner documents rather than sample files.
- Reporting. Leadership wants to see the acquired business inside the combined numbers on the first close. That only works if the account mapping and the subsidiary decisions were made with that report in mind.
Why nothing broke
I want to be careful, because “nothing broke” is the kind of claim that invites a story about the thing that did. But across every wave, nothing did that reached a customer, a partner, or a close. That was not luck. It came down to four decisions, each a little tedious at the time.
We rehearsed every cutover in a sandbox first, end to end, with real data, until the rehearsal was uneventful. We ran the old system and NetSuite in parallel and reconciled them with reports until the numbers agreed, then reconciled again. We held the Day 1 line ruthlessly, so the scope of any single cutover stayed small enough to actually verify. And I kept the master-data cleanup on my own desk instead of treating it as somebody else’s import job.
The hard lesson inside all of that is the item master. If I could hand one sentence to someone about to absorb an acquisition, it would be this: the deal will not fail on the general ledger, it will fail on units of measure and pricing, so start there and start early.
A checklist you can steal
- Decide subsidiary structure and map the full chart of accounts before any data moves.
- Inventory every integration and EDI relationship the acquired company has, and who owns each one.
- Clean the item master first: duplicates, units of measure, pricing. Assign a single owner.
- Merge customers and vendors deliberately, with terms, tax, and EDI IDs reconciled.
- Split the work into waves, and write down the Day 1 line for each one.
- Rehearse each cutover in a sandbox with real data until it is uneventful.
- Run parallel and reconcile with reports. Do not switch on a wave that does not tie out.
- Test EDI with real partner documents, and cut it over last.
- Plan the month after each wave as carefully as the weekend of it. The first 90 days rules still apply, they just apply several times.
Absorbing a company into NetSuite is the highest-stakes version of the integration work I have spent years on, and it is the part of what I do I would put on the table first with anyone about to sign a deal. The best outcome is the quiet one: the acquired business shows up in the numbers one morning and keeps running, and only the people who did the work know what it took.