Merger integration checklist for engineering firms: systems and records

What belongs in an engineering firm's merger integration checklist?#

An engineering firm's merger integration checklist covers four workstreams: people, clients, finance and records. The records workstream spans the ERP, CAD and BIM files, the common data environment and file servers, email, QA/QC logs and the archives of closed projects, and it is the one most often left until systems are already being switched off.

Records carry more weight in engineering than in many industries. Closed projects can carry professional liability for years, state licensing rules may require sealed drawings and calculations to stay retrievable, and client contracts set confidentiality and ownership terms that travel with the files. The same records are what make a firm's history useful later, whether for internal knowledge tools or for licensing to AI developers.

Before close: what to inventory#

The pre-close records inventory should name every system and archive the acquired firm uses, who administers each one and what its license says about transfer. Collect it during diligence, when the people who know the systems are still there and motivated to explain them.

• 1ERP and accounting: Deltek Vantagepoint, Ajera, BQE Core or another system, with years of history and deployment type.
• 2Design files: Revit, Civil 3D, MicroStation and other CAD or BIM platforms, with storage locations and version history.
• 3Common data environment and file servers: ProjectWise, Autodesk Construction Cloud, SharePoint or network shares.
• 4Project controls: RFI, submittal and QA/QC logs, including any kept on contractor-hosted platforms.
• 5Email and chat archives, and the retention settings applied to them.
• 6Paper archives, flat files and offsite storage, with any indexes that exist.
• 7The records retention policy, legal holds and open claims.
• 8Software licenses, and whether each can be assigned to the buyer.

The integration checklist by phase#

The integration checklist runs in four phases, each with a systems action and a records action. Phases overlap in practice; the order matters more than the calendar.

ERP consolidation: decide before you migrate#

ERP consolidation is where engineering firms commonly lose project history. Converting only open projects and opening balances is quicker, but it strands years of phase budgets, hours and revisions in a database nobody can open once the license lapses.

Decide three things before migration: how old project numbers map to the new scheme, whether closed projects are converted or kept in a read-only legacy instance, and who keeps the credentials and database backups for that instance. Put the mapping in a table that finance and operations can both find.

Keep timesheet and phase detail even when it is not converted. Plan-versus-actual history shows how the acquired firm really ran its projects, and it is hard to rebuild once the source is gone.

Archives: keep, migrate or destroy?#

Archive decisions after a merger should follow one retention schedule, adjusted for legal holds and the liability period for each project. Statutes of repose and limitation periods vary by state and by type of claim, so set retention with counsel rather than by habit.

Destruction is the only irreversible choice in the table. Before destroying anything the schedule allows, confirm that no hold applies, check client return-or-destroy terms and record who approved it.

Files past the liability period are where destruction and later licensing decisions meet. Once destroyed, they cannot be reviewed for licensing or internal knowledge use; kept indefinitely, they extend confidentiality exposure and storage cost. Decide by record family rather than by project: internal process records such as QA comments, RFI logs and staffing histories are often worth keeping and indexing, while duplicate drawing sets and superseded drafts rarely are.

Build a rights index as you go#

A rights index is a spreadsheet that records, for each project or record set, what the firm may do with it. Building it during integration costs little, because the team is already opening contracts and folders.

Useful columns include the client, the contracting entity, the contract form (AIA, EJCDC, ConsensusDocs or client paper), ownership and license terms for drawings, the confidentiality clause and its survival, any public-agency or security sensitivity, legal holds and whether the contract was assigned at closing.

Buyers of licensed data may ask for similar metadata. The Data & Trust Alliance's Data Provenance Standards, for example, include elements for license to use, intended data use, confidentiality classification and the location of consent documentation. An index built during integration already answers many of those questions.

Illustrative: a civil firm integrates a transportation practice it bought outright#

Illustrative: a fictional regional civil engineering firm buys all the shares of a smaller transportation engineering firm. Because it is a stock purchase, the acquired company keeps its own contracts and records, so the integration work is about systems, custody and retention rather than title. The acquired firm runs BQE Core for time and billing, keeps drawings in ProjectWise and has an email policy that deletes departed staff mailboxes after a set period.

On day one, IT pauses the automatic mailbox deletion and the records manager suspends the shredding schedule for offsite boxes until legal holds are confirmed. During consolidation, the controller converts open projects into the buyer's Vantagepoint, keeps a verified read-only BQE Core snapshot for closed projects and publishes a table mapping old project numbers to new ones.

The rights index fills in as contracts are opened. Most closed projects were for state transportation agencies under agency contract forms, so they are marked for exclusion pending review. Private land development work under standard owner-engineer forms is tagged as a candidate for later licensing of internal process records, such as QA comments and staffing histories, with the acquired company as the entity that would sign.

How SourceX fits after a merger#

SourceX starts with the Supply step of the SourceX five-step transaction: confirming which legal entity holds the records and who can sign for it. After a merger that may be the buyer, the acquired entity or a seller entity that kept closed-project archives.

The rights index feeds the Rights step directly, and the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for each package. Nothing is shared during the initial fit check, and large archives stay in the firm's own storage.