Merging two specification orgs without losing the compliance record
Two companies merge. Two brands get bought and folded into a third. A division gets carved out and sold. Somewhere in the diligence deck it says the two Specright environments will be consolidated, and everyone nods, because it sounds like an IT task.
It is not an IT task. It is a decision project with a data migration attached, and the decisions are the part that takes the time.
Start by admitting you are not replicating the source
The first thing to settle, in writing, is whether you are rebuilding the acquired environment inside the surviving one or moving its data into the surviving one’s model. Those are completely different projects, and teams routinely scope the second while expecting the first.
Rebuilding means recreating objects, fields, automations, rollups, validation logic, approval flows and integrations. Moving data means mapping what exists into structures that are already there, transforming where the shapes differ, and accepting that some of the source model does not survive.
The second is usually the right call, because the surviving environment is the future operating model and the acquired one is not. But it has to be said out loud at kickoff, or every mapping conversation turns into a negotiation about why a field is missing.
Discovery is a phase, not a call
On a consolidation of any size, expect discovery to run several weeks and produce four artifacts: a mapping workbook down to field level, a picklist value translation worksheet, an archive decision log, and a list of objects nobody has decided on yet.
The scale surprises people. On one recent consolidation, the packaging specification object alone had nearly 500 source fields in review, with only about a third having an obvious target. The ingredient object had 166. Those numbers are not unusual for a mature spec library, and they are the reason a mapping workbook cannot be assembled in an afternoon.
The undecided list matters as much as the mapped one. Contaminant structures, active ingredient breakdowns, analytical methods and fill assembly controls tend to sit in that bucket. Naming them early as open decisions keeps them from being quietly assumed into scope.
The packaging hierarchy almost never matches
This is the single most common transformation in a spec consolidation. One environment models packaging as a deep tree, with several levels between the finished good and the component. The other models it flat, with connections carrying the relationship data instead of nesting.
Neither is wrong. But a flat target cannot receive a deep source without a rule that says what happens to the middle layers. That rule has to be validated against real examples early, and signed off, because everything downstream depends on it. Get it agreed in week three and the rest of the project is mechanical. Discover the mismatch during trial loads and you have lost a month.
Picklists will eat more time than fields
Two spec libraries built by different teams will not agree on their vocabulary. One says Corrugated, the other says Corrugate. One has eleven board grades, the other has thirty. Somebody has a picklist value that is just a supplier name.
A value translation worksheet, done field by field, is the unglamorous artifact that prevents six months of dirty reporting. It is also the moment where the business gets to consolidate a vocabulary it has wanted to clean up for years, which is worth framing as an opportunity rather than a chore.
Decide what to migrate and what to archive
Not all of it should move. Regulatory and compliance-heavy detail, historical calculation data, retired formulations and superseded versions often need to be retained for audit without being operationalized in the new environment.
The question to answer is what an auditor would actually need to retrieve, and in what form. In a lot of cases a structured export with a documented retrieval path satisfies the requirement, and loading that data into live objects would only slow the system and confuse users. That decision needs a named owner and a written retention rule, because it also determines what you are allowed to delete from the source later.
Ownership mapping is a client deliverable
Records need owners in the target. The source owners either do not exist there or exist under different accounts. No migration partner can guess this, and a default of assigning everything to one admin account breaks any sharing model and every ownership-based report on day one.
Ask for an old owner to new owner mapping in the same workbook as the field mapping. It is a small file that prevents a large cleanup.
Purge last, and only after reconciliation
The instinct after cutover is to shut the old environment down and stop paying for it. Hold that for a cycle. Run reconciliation first, by object, comparing record counts and sampled field values rather than a single grand total. A matching total can still hide records that landed on the wrong parent.
Then check dependencies before deleting anything. Shared records, cross-region references and retention obligations all create reasons that a record which looks migrated cannot be purged yet. Cleanup should be an approved, scheduled step with its own signoff, not the last thing somebody does on a Friday.
How long it really takes
For a consolidation involving a mature spec library with packaging transformation, archival decisions and source cleanup, four to five months from signature is a realistic plan, and roughly a third of the effort sits in extraction and transformation rather than in the load itself. Project management is not overhead on this kind of work, it is the mechanism that keeps decisions arriving on time, and decisions arriving late is the single biggest cause of slipped dates.
Add scope carefully. Bringing an additional region’s data in, especially where compliance retention rules differ, is a meaningful increment and should be planned and priced as one rather than absorbed.
Our Specright practice page covers the consolidation and enhancement work in more detail, and the data migration page explains how we reconcile and prove a load. If you are staring at two environments and a deadline, send us the object list and we will tell you where the hard parts are.
