Why merger integration flows need an exit plan before they go live
Two companies that have just merged usually run duplicate ERPs, CRMs and directories, and leadership still needs combined results for a reporting deadline. Interim automation can bridge that gap, but every temporary flow needs a written exit plan before it goes live: who owns it, which systems it touches, when it is retired and what replaces it. Without that plan, a bridge built in weeks tends to become permanent infrastructure that nobody remembers how to maintain.
Temporary flows still carry production data, credentials and control evidence. A flow that copies invoices between two ledgers handles financial records, holds service account credentials for both sides and produces the execution history that an auditor may ask to see. If the combined entity falls under Section 404 style internal control work, the SEC staff allow a newly acquired business to be excluded from management's assessment for a limited period only, so the interim flows may need to be documented as IT general controls for the year they run. Confirm with your auditors which of your flows touch financial reporting risks before you decide how much evidence to keep.
On platform choice, the exit plan should follow the job. n8n suits fast interim integrations between SaaS tools and internal APIs, but confirm the Sustainable Use License and any .ee components against how the flows will be used, especially if a subsidiary or partner will consume them. Node-RED fits lightweight event flows and plant-like device or message handling, and its Apache-2.0 license is simpler to clear. Temporal fits long-running cross-system processes, such as account migrations that must survive restarts, and its self-hosted deployment needs authorization and network controls configured before any production data passes through it.
Which regulations and controls apply to interim merger automation
This table maps each regulation or control that can reach interim automation during a merger to the build decision it forces. Read each row as a question to settle before the first flow is deployed, since the answer usually determines where flows run, who holds credentials and what evidence must be kept. The main takeaway is that the regulatory clock often starts at close, not at go-live, so the temporary flows need the same records as permanent ones.
| Requirement | What it means for the build | Evidence an assessor will expect |
|---|---|---|
| SEC ICFR exclusion for an acquired business (one year, one annual report, disclosure) | Flows that move financial data from the acquired company must be scoped so the acquired business can be excluded only within the SEC limits, so keep a list of which flows touch its ledgers. | A dated inventory of acquired-company flows, the acquisition date and the disclosure of the excluded business and its significance. |
| SEC Release 33-8810 IT general control areas | Treat interim flows that touch financial reporting data as in scope for program change, computer operations and access controls, and cover only the IT general controls tied to financial reporting risk. | Change approvals for workflow edits, job monitoring records and access reviews for the workflow platform. |
| Form 8-K Item 1.05 and third-party oversight under 17 CFR 229.106 | Interim flows that call outside vendors or integrators must be logged so the company can describe oversight of those providers and trace an incident quickly enough for a four-business-day decision. | Inventory of external endpoints per flow, incident runbooks that name the owner and a record of how third-party providers were overseen. |
| NIS2 contact details, IP ranges and change notification within two weeks (Article 3(4)) | If the combined group is in scope, the competent authority needs updated entity details and IP ranges, so any new egress addresses created by merged network changes must be tracked. | A maintained register of entity details and IP ranges, with a process to notify changes within two weeks. |
| DORA Article 28(3) register and Article 28(8) exit strategy | Where a flow supports a critical or important function at a financial entity, the temporary automation must appear in the ICT service register and have a tested exit and transition plan that covers retirement. | Register entries for each arrangement, a documented exit plan and test records showing the transition was rehearsed. |
| EU Data Act switching and on-premises provisions (Articles 23, 25 and 29) | Where a data processing service is used to bridge systems, the contract must allow switching to another provider or to on-premises infrastructure, so self-hosted automation keeps exit options open. | Contract clauses covering notice periods, transitional periods and porting of exportable data, plus a tested export of workflow definitions. |
| EDPB Guidelines 05/2021 on remote access by a non-EEA acquirer's staff | If acquirer staff outside the EEA can view or administer flows that process EU personal data, that access is a transfer, so the design must either keep administration inside the EEA or put a Chapter V transfer tool in place before access is granted. | Access lists showing the location of each administrator, the transfer tool relied on and a record of who viewed execution data. |
| GDPR Article 28(3)(a) documented instructions and Article 30 records | The acquired company or integrator acting as processor may run flows only on documented instructions, so each interim flow needs a written purpose, data categories and security measures recorded in the processing register. | Documented instructions per flow, processing records that describe the Article 32 security measures and a log of changes to those instructions. |
| 45 CFR 164.314(a) HIPAA business associate terms | If a flow handles ePHI, the business associate contract must require Security Rule compliance, flow the terms to subcontractors and require incident reporting to the covered entity, which means integrators and hosting providers on the flow must be named in contracts. | Executed business associate agreements covering each party that can reach ePHI through the flow, plus subcontractor flow-down records and incident reporting procedures. |
Which data and systems interim flows actually touch
Start by inventorying the flows before writing any of them. In most interim integrations the same few patterns recur: order and invoice sync between duplicate ERPs, customer and opportunity sync between CRMs, user and group sync between two directories, and reporting feeds that pull trial balances and sub-ledger extracts into the combined close. Each pattern touches a different class of data. Order and invoice flows carry financial records and often customer identifiers. CRM flows carry contact details, which are personal data. Directory flows carry names, email addresses, group memberships and sometimes privileged accounts, which are personal data and also drive access rights. For each flow, record the source system, the target system, the fields moved, the owning business process and the legal entity that controls the data. (Illustrative: a single invoice sync may move a customer's name and billing address from one entity's ERP into a second entity's ledger, which makes two controllers relevant.)
The credential question is where most interim designs fail. A flow that reads from the target ERP needs a service account in that system, and whoever holds the credential in the workflow tool can act inside the target company. Confirm, for each connector, who issues the account, who approves its scope, who rotates the secret and whether the account is shared between both companies. Where the workflow platform is n8n, the encryption key that protects stored credentials must be shared with worker and webhook processors in queue mode, so anyone who can reach those processes can reach the credentials; document who holds that key. Temporal, if used for durable orchestration, is a separate case: its self-hosted default authorizer allows every API request, so access must be restricted before any cross-company data passes through it.
Acquirer staff often need to see the target's systems to run the integration, and that access is a transfer question, not only an access question. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, counts as a transfer, so a non-EEA acquirer's administrators who log into an EU target's ERP or directory need a Chapter V transfer tool. Ask legal counsel to classify each access path before it is granted, and keep the GDPR Article 30 records of processing current for the interim flows. If the target is a regulated entity, check whether its DORA register of ICT arrangements or its NIS2 notifications to a competent authority must list the new workflow platform or the new connected provider. Confirm these obligations with counsel; the register and notification duties apply to the entity, not to the integration team.
Which open-source platforms fit interim merger flows
Interim flows during a merger usually need to be quick to build, easy to watch and safe with credentials that belong to two companies at once. The platforms below handle those needs differently, so the choice depends on whether the flow is an integration between applications, an event or directory sync, or a long reconciliation that must survive restarts.
n8n for short-lived integrations
n8n suits interim flows that copy records between duplicate CRMs or ERPs and are retired within a known window. The Sustainable Use License permits use for your own internal business purposes, but not offering the flows to customers, so confirm that the merged entity's use is internal. Files marked .ee need an n8n Enterprise License. SSO, LDAP and Git-based environments appear only on the Business and Enterprise plans, and multi-main high availability is limited to Enterprise self-hosted deployments. Confirm which of these the merged team needs before the first flow is built.
Node-RED for directory and event sync
Node-RED is licensed under Apache-2.0, which leaves fewer licensing questions for an interim team. Its flow-based model fits event-style and directory-style work, such as propagating user or group changes between two Active Directory forests or LDAP trees during a transition. Because flows are often edited by people who are not developers, confirm who owns each flow, how edits are reviewed, and whether editor access is restricted before the flows touch identity data. Node-RED 5.0.8 was published on October 8, 2026, so pin the version you test.
Temporal for long reconciliations
Temporal fits multi-step reconciliations that span days, such as matching customer balances between two ledgers, retrying failed calls, and resuming after an outage. The server is MIT licensed, and Temporal Server 1.32.1 was published on October 8, 2026. Self-hosted Temporal uses a noopAuthorizer by default, which allows every API request without authentication, so you must configure an Authorizer and a ClaimMapper before any flow runs. Keep the services off the public internet and confirm the persistence and visibility stores you will operate.
Camunda licence limits for production
Flowable and Camunda both model BPMN processes, which can be useful when a merger has approval steps, such as access requests that require sign-off from both legacy organizations. Flowable is Apache-2.0 licensed. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. If the interim process must run in production on Camunda, confirm the commercial terms with the vendor before design work starts.
Choosing across the four
Use the platform that matches the flow's shape, not the one already in the team's toolkit. Short point-to-point syncs favor n8n or Node-RED, while long, retry-heavy reconciliations favor Temporal. Whichever you choose, record the owner, credential vault location and retirement date for each flow in a register, so temporary automations do not outlive the systems they bridge. Ask the implementation partner to confirm this mapping against your license, edition and hosting constraints.
Deployment choices when the two companies have different hosting rules
When both companies host in the same country and can share infrastructure under one legal framework, the simplest pattern is a single self-hosted automation environment that both sides' flows call. The interim flows still need separate ownership, so the design should separate where each company's credentials are stored and who can edit them, even though the servers are shared. This is the least complex case, but it is the one most often under-designed because teams assume shared hosting means shared trust.
- Placement: Run n8n or Temporal in one account or data center segment with separate projects or namespaces for each company's flows.
- Encryption keys: Keep one n8n encryption key per instance, and record which company's credentials it protects, since workers need the same key in queue mode.
- Credential split: Store each company's credentials under its own owner and restrict editing rights to that company's staff.
- Temporal exposure: Keep Temporal services off the public internet and restrict access to trusted internal networks.
- Visibility store: Use Elasticsearch or OpenSearch for Temporal advanced visibility once executions exceed a few, not PostgreSQL as the long-term index.
Confirm with each company's counsel that a shared execution log does not itself reveal data one side is not allowed to see.
When an EU target's systems hold personal data and the acquirer's staff are outside the EEA, remote access to those systems for support or administration can count as a transfer under EDPB Guidelines 05/2021. The automation layer is often where that access happens, because administrators open flows, read execution data and rotate credentials. The design therefore keeps the target's automation inside EU infrastructure and controls who from the acquirer can reach it, with a documented transfer tool where access is still required.
- Placement: Host the target's flows and their execution data in an EU region or on premises, and keep the acquirer's administrative console outside that path.
- Encryption keys: Hold the target's encryption keys inside the EU estate under the target's control, not in the acquirer's key store.
- Credential split: Give acquirer staff named, time-limited access to target flows only where a Chapter V transfer tool is documented.
- Processor terms: Record the controller's documented instructions for any processing the acquirer performs, as GDPR Article 28(3)(a) requires.
- Record of processing: Describe the Article 32 measures for these flows in the records under Article 30.
Ask counsel which transfer tool applies and whether the target's processing records already list the new processor.
When the acquirer runs a different identity provider, the interim automation must authenticate people from both directories without creating a shadow admin path. The main decision is whether each company's staff log in through their own provider, or whether one provider is federated to the other. Both options affect who can approve workflow changes and who can view credentials, so the role mapping is as important as the login method.
- Placement: Keep the automation instance where the target's systems run, and federate the acquirer's identity provider into it rather than copying accounts.
- Single sign-on: Confirm which SSO options your edition includes, since n8n lists SSO and LDAP only on its Business and Enterprise plans.
- Role mapping: Map each provider's groups to project roles, and exclude unmapped users by default.
- Temporal access: Temporal's default Authorizer allows every request, so configure an Authorizer, a ClaimMapper and OIDC for the Web UI before any cross-company access.
- Encryption keys: Keep key custody with the company that owns the credentials, not with whichever identity administrator holds broader rights.
Confirm with the identity teams how group changes and deprovisioning will flow between the two directories during the overlap period.
How to roll out and retire temporary automation in phases
The sequence keeps every interim flow owned, licensed, secured and monitored from the day it is inventoried until the day it is removed. Each phase ends with a record that auditors and the integration steering group can check.
Inventory and classify every interim flow
Start by listing every automation that bridges the two companies: flows between duplicate ERPs, CRMs and directories, plus scripts and scheduled jobs that nobody has formally registered. For each item, record the systems it touches, the data it moves, the credentials it uses, a named business owner and technical owner, and a planned end date tied to a consolidation milestone. Classify each flow by data sensitivity and by whether it supports financial reporting or a regulated process. The output is a register of flows, and the step is done when every flow in the register has both owners and an end condition, and no integration runs outside it.
Review controls and license terms
Before anything is rebuilt, check the controls that apply to the flows in the register. For flows that touch financial data, confirm with the finance and internal audit teams which IT general control areas they support, since the SEC's guidance on management's ICFR assessment names program changes and access to data among them. For EU personal data, confirm the GDPR processing records and any transfers created when the acquirer's staff or systems reach target data. Confirm the license terms of the chosen automation tool for internal use, especially for fair-code products such as n8n, where the Sustainable Use License limits use to internal business purposes and files marked .ee need an enterprise license. The output is a control and license memo signed by the owners, and the step is done when each open question has a named answer.
Build the secure platform with SSO and key handling
Deploy the automation platform inside the infrastructure that both parties' security teams have approved, with network access limited to trusted internal networks. Connect administrator and editor access to the identity provider so every change is attributable to a person. Decide who holds each credential: the business owner of the target system should own the connection, and the platform team should own the encryption key and its custody. For queue-mode deployments of n8n, the main instance's encryption key must be shared with every worker and webhook processor, so plan that distribution and its rotation before go-live. For Temporal, enable authorization instead of relying on the default, which allows all API requests when no Authorizer is configured. The output is a build record covering SSO configuration, credential ownership, key custody and access roles, and the step is done when a test user cannot reach a credential they do not own.
Pilot flows with monitoring and alerting
Move one low-risk interim flow into the new platform first, with alerting wired to the technical owner before it runs against live data. Define what a failure looks like for that flow, such as a rejected record, a missed run or a credential error, and route those events to a channel that someone watches. Confirm the execution data retention settings, since execution history can contain personal or financial data, and confirm where logs are stored and who can read them. Test the retry and error-handling behavior with a deliberately broken input. The output is a pilot report with monitoring screenshots, a list of alerts tested, and the agreed retention setting. The step is done when the owner has received and acknowledged a test alert.
Cut over and run both paths in parallel
For each flow that moves, run the old and new paths side by side for a period the business owner agrees in writing, then compare outputs for the same inputs. Record every difference, decide whether it is a defect in the new flow or in the legacy process, and fix it before cutover. Keep the rollback path documented and tested, so the old flow can be restored if the new one fails. Where a flow feeds financial reporting, keep the change approval record for each edit to the workflow. The output is a cutover log listing each flow, its reconciliation result, the approver and the rollback procedure. The step is done when the business owner signs off the reconciliation and the old path is switched off.
Decommission and revoke credentials
When the consolidated systems take over a process, remove the interim flow from scheduling and disable its triggers and webhooks first, then archive the workflow definition and its execution history according to the retention decision made earlier. Revoke every credential and API token the flow used, at the target system and in the platform's credential store, and rotate any shared secret that the flow knew. Confirm that no other flow still depends on the retired connection. Check whether any third-party provider holds a copy of the data, and request deletion where the contract allows it. The output is a decommission log per flow with the revocation timestamps, the archive location and the approver, plus evidence of removal such as the disabled scheduler entry and the revoked token list. The step is done when the register shows the flow as retired with that evidence attached.
Close the register and retain the evidence
Once every interim flow is retired or moved into permanent ownership, close the register and pass the complete set of records to the integration steering group, internal audit and, where relevant, the compliance team preparing evidence for external assessors. Confirm that the register reflects the final state of each flow, that the control memo's open questions are answered, and that the decommission logs are complete. Ask the implementation partner to confirm that the retention period for these records matches the policies of both companies. The output is a closed register and an evidence index, and the step is done when the steering group accepts the index and the platform itself is either retired or placed under normal lifecycle management.
Which evidence auditors ask for on interim flows
This table lists the evidence an assessor is likely to request for temporary merger flows, the component that produces each item, and where the record usually goes missing. Read it as a checklist for what to keep from day one, not as proof that any item satisfies an audit. Auditors decide sufficiency for each engagement.
| Evidence item | Produced by | Gaps to check early |
|---|---|---|
| Register of ICT arrangements covering each interim flow and its providers | Your third-party register, updated from the flow inventory | Flows built by one team and absent from the register |
| Flow inventory with named owner, business purpose and planned end date | Version-controlled inventory maintained alongside the n8n or Temporal projects | Owners who have left the acquired company, or no end date |
| Change approvals for every flow edit, including credential changes | Ticketing system linked to Git commits or workflow promotion records | Edits made directly in the production editor with no ticket |
| Access logs showing who could view or run each interim flow | n8n user management and SSO logs, Temporal namespace role mappings and audit logs | Shared admin accounts or the default Temporal noopAuthorizer left in place |
| Credential ownership records mapping each secret to a system and a responsible person | Credential store of the workflow platform, documented in your secrets inventory | Credentials created by a departing integrator and never reassigned |
| Execution logs and alert records for failed or retried runs | n8n execution data, log streaming on Business or Enterprise plans, Temporal visibility search | Execution retention shorter than the audit period or alerts sent to an unmonitored mailbox |
| Transfer documentation for flows that move personal data to or from the acquirer's systems | Records of processing and transfer assessments, maintained by privacy and legal | Acquirer staff given access to EU data without a documented transfer tool |
| Decommission records showing shutdown date, credential revocation and data disposal | Change ticket, platform configuration history and credential revocation log | Flows switched off but credentials still valid and execution data still retained |
What to ask an implementation partner before a merger automation project
Start with credential separation, because it decides whether the merged company can later cut off the other side. Ask the partner how each company's credentials are stored, which encryption key protects each set, and who holds administrative rights over each. Ask them to show, in a test environment, how a flow that touches both companies' systems is limited to the credentials it needs, and how a credential belonging to the acquired company is revoked without breaking the acquirer's flows. For n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read credentials from the database (see the n8n queue mode documentation). Ask how that shared key is distributed, rotated and kept out of the other company's administrators' reach, since a single key shared across both companies' workers means one key holder can read both sides.
Next, ask how the partner inventories flows and sets an end date for each one. A usable inventory lists the owner, the two systems joined, the credentials used, the run volume and a planned retirement trigger, such as a cutover date or the decommissioning of a duplicate directory. Ask which features need a paid n8n plan before you commit to a design. The n8n pricing page states that single sign-on, LDAP, environments with Git and log streaming are included only in the Business and Enterprise plans, and that multi-main high availability is limited to Enterprise self-hosted deployments. Confirm the current terms with n8n directly, because plan contents change. For Temporal, ask how the Authorizer is configured. A self-hosted Temporal server with no Authorizer uses the noopAuthorizer, which allows every API request, so ask for the claim mapping, namespace roles and the mTLS settings in writing before any cross-company namespace is opened.
Finally, ask how the partner will evidence retirement and handle personal data. Retirement evidence should include the decommissioned credentials, disabled schedules, exported execution history and a signed change record for each retired flow. Ask how that evidence supports the control reviews your auditors will run. On data, ask who is considered the controller and processor for each flow, and how remote access by an acquirer's staff to EU personal data is treated. Under EDPB Guidelines 05/2021, remote access from a third country counts as a transfer and needs a Chapter V transfer tool, so the partner should map every flow that crosses that boundary and document it. Ask for their written process for updating those records when a flow is retired, and confirm whether the transfer documentation is your legal team's responsibility or theirs.
How much effort and time do merger automation projects take?
What drives the cost of automating workflows during a merger?
The main drivers are the number of flows, the number of systems each flow touches, the number of credential sets that must be created and rotated, the licence tier needed for the features you use, and the compliance scope of the data that moves. A flow that copies customer records between two CRMs carries more review, access control and logging work than a flow that moves a daily status file between two internal tools. Each additional system adds connector testing, error handling and an owner to confirm. Ask for a quote that lists flows, systems and credential sets as separate line items so you can see which choices move the price.
Which merger automation costs are one-time and which recur?
Build, testing, credential setup, documentation and the first production cutover are one-time costs. Recurring costs include the platform run cost, infrastructure for hosting and monitoring, paid licence tiers if you need single sign-on or environments, and ongoing maintenance when connected systems change their APIs or schemas. Retirement is one-time but easy to underestimate, because each temporary flow must be removed, its credentials revoked and its execution data archived or deleted. If you use a task-priced SaaS tool instead, the recurring cost grows with volume, which matters when a merger generates many temporary runs. Ask the partner to separate these categories in writing.
Can our internal team build and run merger automations on its own?
Many organizations can, provided they have engineers who know the platform, the systems being bridged and the security controls the data requires. The harder part is usually not the first build but the parallel work: keeping two identity sources, two ERPs and two CRMs in step during the merger, documenting who owns each credential set and retiring flows on schedule. Internal teams often already have full workloads during an integration, so the question is capacity, not capability. A partner is most useful for fixed-scope work such as building the initial interim flows, hardening the platform and handing over documentation and runbooks. Decide which parts you will keep and which you will buy before you request a quote.
How long does a merger workflow automation project take?
The supplied research does not give a duration for merger automation work, so no timeline should be assumed from this page. Duration depends on how many systems are in scope, how many flows must be built and tested, how long change approvals take in each company, and how many environments must be validated before production. Ask the partner for a written scope that breaks the work into phases with deliverables, dependencies and the approvals each phase needs. A fixed-scope agreement sets the scope, deliverables and timeline in writing before work begins, which gives you a basis for comparing proposals. Treat any date that is not written into that scope as an estimate.
What do we need to provide to the automation team during a merger?
The team needs named owners for each system being bridged, read and write access to test and production environments under your change process, and agreed change windows for production cutovers. It also needs a list of the credentials each flow will use, the data classes it will move, and the approvals required by your compliance or legal teams. If the two companies have different identity providers, someone must decide which one controls access to the automation platform during the transition. Missing owners are the most common reason interim flows stall, so confirm these people and their time commitments before the project starts.
What happens to the project if the merger timeline changes?
A delayed close usually extends the interim period, which keeps temporary flows and their credentials in service longer than planned. A pulled-forward close can shorten the window for testing and retirement. Either change should trigger a review of the written scope, the retirement plan and the change windows, because flows built for a specific cutover date may need to be re-tested against new system versions. Ask the partner how scope changes are priced and approved under the agreement, and how temporary flows are documented so they can be retired on either timeline without losing track of who owns them.
How DeployOpen scopes and supports merger automation
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a merger automation program, that means the interim flows, the n8n or Temporal hosting, the credential vault arrangements and the monitoring stack are built in the environment that both companies' data will actually cross. Before any work starts, the scope should name each interim flow, the two systems it connects, the data classes it moves, the environments it runs in and the date each flow is to be retired. Those items define what gets built and what does not. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. For this topic, the written scope should state who owns each credential after close, which decisions belong to the acquirer's identity team and which to the target's, how execution history is retained, and what the retirement criteria are for every temporary flow. Changes to that scope after signature should go through a written change request, so the retirement plan does not drift as the consolidation timetable moves. Ask any partner, DeployOpen included, to show a sample scope document and a retirement checklist before you sign.
Once the interim automation is live, the work does not end at handover. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which suits integration programs that run longer than the original build because ERP and directory consolidation often slips. A retainer should cover patching the workflow engine, rotating the encryption key used for stored credentials, reviewing access to the editor and reviewing flows that still depend on a system scheduled for shutdown. Confirm in writing what the retainer includes, how incidents are escalated and who is on the hook when a flow fails at two in the morning on a Sunday. DeployOpen also prepares systems, controls and evidence for compliance assessments, such as change records, access reviews and execution logs. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the reader should bring the relevant assessor into the scope conversation early, especially for the SOX, DORA or data transfer questions raised in the other sections of this page.
