Why process harmonization after a merger is different
After an acquisition, the acquirer usually runs two BPM suites, with running instances on both sides and approvals that cannot pause while the integration is planned. The goal is one engine with defensible evidence for every approval, not a feature comparison between products. Timing matters because the SEC lets management exclude a newly acquired business from its internal control over financial reporting assessment only for a limited period. The exclusion cannot extend beyond one year from the acquisition date or across more than one annual report, and the excluded business and its significance must be disclosed. That window is the practical deadline for showing that approvals on the acquired side are controlled, traceable and tested.
Confirm the acquisition date with legal and finance, then count the annual reports that would carry the exclusion. Inventory every approval path on the target side, including which ones touch financial reporting risk, because the SEC guidance focuses IT general control evaluation on controls that address those risks. Identify which running instances must finish on the legacy suite and which can be migrated, since that split drives the cutover plan.
On platforms, the short answer is that Flowable under Apache-2.0 has a clear production licensing position, with its engines, REST APIs and database support documented in the open source materials. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so Camunda 8 is viable only where those terms are acceptable for the production estate. Have legal review the license text against your production plans before any engine is selected.
Which regulatory and contractual requirements shape the harmonization
This table maps the regulatory and contractual requirements most likely to affect how two companies' approval processes are merged onto one engine, and what each one means for the build. Read each row as a question to settle before design starts, since several requirements decide where process data may sit, who may access it, and what evidence the engine must keep. The main takeaway is that data residency, access by an acquirer's staff and exit or switching terms should be fixed in scope before any process is migrated.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| SEC ICFR exclusion for acquired businesses | Management may exclude a newly acquired business from its internal control assessment for a limited period, not beyond one year from acquisition and not across more than one annual report, with disclosure of the exclusion. | Track which business units run on the legacy suite and which on the new engine by date. Keep the cutover calendar aligned with the exclusion window the finance team will rely on. |
| IT general controls in scope | SEC guidance names program development, program changes, computer operations and access to programs and data as example IT general control areas, limited to controls that address financial reporting risk. | Identify which approval processes support financial reporting controls. Apply change approval, testing and access control to those BPMN models and the engine hosting them before cutover. |
| SEC Item 1.05 incident disclosure and third-party oversight | Material cybersecurity incidents require a Form 8-K Item 1.05 filing, generally within four business days after materiality is determined. Annual reports describe oversight of third-party service provider risk. | Log security events from the engine and its integrations with enough detail to support materiality decisions. Record the implementation partner and hosting providers as third parties in oversight records. |
| NIS2 notification of changes | Entities must give their competent authority their name, contact details, IP ranges, sector and service Member States, and notify changes without delay and in any event within two weeks. | If the merged group or the target falls in scope, update registrations when hostnames, IP ranges or service locations change during the merger. Put the notification step in the cutover checklist. |
| DORA register and exit strategy | Financial entities keep a register of all ICT service arrangements, and services supporting critical or important functions need tested exit strategies and transition plans. | Record the BPM engine, hosting and support arrangements in the register. Treat a tested migration path off the engine as a build deliverable, not an afterthought. |
| EU Data Act switching rights | Data processing providers must support switching to another provider or on-premises infrastructure, with a maximum two-month notice period, a 30-day transitional period, porting of exportable data and no switching charges from 12 January 2027. | If the target uses a hosted process platform, check whether these switching terms apply to its contract. Design exports of process instances, history and forms in open formats such as BPMN and JSON so porting remains practical. |
| GDPR Articles 28 and 30 records | Processors act only on documented controller instructions, including for transfers, and processing records describe Article 32 security measures where possible. | Document which company is controller for each process's personal data after the merger. Keep processing records for each business unit and the security measures applied to the engine and its database. |
| Cross-border access by an acquirer | Remote access to EU personal data from a third country, including for support or administration, is a transfer under EDPB Guidelines 05/2021 and needs a Chapter V transfer tool. | If a non-EEA acquirer's staff need to view target process data, plan role-based access that is either limited to non-personal views or covered by a transfer tool. Keep the engine's data in EU hosting unless counsel confirms otherwise. |
| HIPAA business associate terms | Business associate contracts must require Security Rule compliance, flow terms down to subcontractors handling ePHI and report security incidents to the covered entity. | Where a process carries health information, confirm these terms cover the implementation partner, hosting provider and any subcontractor with access to process variables and logs. Avoid storing health details in process variables without a documented need. |
| PCI DSS validation scope | Validation is documented on official PCI SSC templates, and payment brands decide which entities must validate. | Determine whether any merged approval process touches cardholder data or systems in scope. Confirm with the acquiring bank or payment brands which entities and systems must be validated before those processes move. |
Which data, systems and process instances are in play
Before any target design is drawn, the acquirer needs a written inventory of what the target runs today. Start with every BPM suite in use, including its product name, exact version, hosting model and the business units that depend on it. Record which processes are modeled in which tool, which were built as custom code outside any engine, and which exist only as spreadsheets or email routing. The same inventory should list running process instances and open human tasks by process definition, with counts, oldest open item, timer and deadline dates, and the people or queues holding each task. Running instances are what determine the migration approach, so they belong in the inventory before any cutover date is discussed.
Next, inventory the data each process carries. Process variables often hold personal data, account identifiers, health or payment details and free-text notes that were never meant to persist. For each variable, record its source system, its storage location, its retention rule and whether it crosses a border after the merger. This matters for the transfer analysis described in the EDPB guidance cited elsewhere on this page, because an acquirer's staff in a third country who can open an EU target's task forms may create a transfer. Decision logic is the third inventory item: find eligibility, pricing, limit and routing rules embedded in Java or scripting code, in exported decision tables, or in spreadsheets maintained by a few people. Each rule needs an owner, a version and the process that calls it.
Identity is the item most often underestimated. List every directory the target authenticates against, such as LDAP, Active Directory, a cloud identity provider or local engine users, along with the group names that drive task assignment and approval limits. The two companies will rarely share a user model, so the inventory should show where the same person appears under different identifiers and which group membership grants which approval authority. Flowable's documentation states that identity management can be replaced by implementing its identity service interface, with an LDAP reference implementation provided. That makes identity mapping a design decision rather than a default. Confirm with the engineering team how the chosen mapping will handle users who leave, change roles or hold authority in both companies.
How deployment constraints change the target architecture
When the harmonized engine runs in the acquirer's own data center, the main architectural question is which relational database the platform team already operates and supports. Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, so a team with an existing Oracle or DB2 estate can usually keep its operating model. Clustering relies on the async executor, which stores lock owners and lock expiration times in the database, so every node in the cluster must reach the same database instance or cluster.
- Database selection: Choose from the supported list based on the operations team's skills, backup tooling and licensing, and confirm the version of each database against the Flowable release you plan to use.
- Lock-based clustering: When a node fails, its expired locks are recovered and other nodes pick up the timers and asynchronous jobs, so the database must be highly available for the engine to keep running.
- Legacy engine data: Migration from the two companies' existing BPM suites may need a staging database alongside the production one during cutover.
- Identity integration: Replace the default identity service with the directory the acquirer already uses, which the Flowable docs describe as an override of the identity service interface.
- Acquirer staff access: Staff in the acquirer's own jurisdiction accessing target data inside the same data center do not create a cross-border transfer on their own, but confirm where each group sits.
Confirm with your database and platform teams which supported database has the strongest existing operating record in your estate.
When the engine runs in a cloud account located in the EU, the platform decisions shift toward managed or self-managed database services in that account, and the data location becomes a documented control. The database choice is still limited to the Flowable-supported list, so a team standardizing on PostgreSQL or SQL Server in its cloud estate should confirm that the chosen service and version are supported before committing. Clustering works the same way as on premises, because the async executor coordinates nodes through database-stored locks rather than through a separate coordination service.
- Database service choice: Confirm whether the cloud provider's managed database offering for a supported engine meets your data residency and backup requirements, and document the decision.
- Node placement: Spread engine nodes across availability zones only if the shared database is reachable from each zone with the latency your timers require.
- Support access: Vendor or partner engineers who log into the account from outside the EU are a remote access event, so set rules for when and how they connect.
- Data Act exit planning: Under the EU Data Act, data processing service providers must support switching to another provider or on-premises infrastructure, with a maximum two-month notice period and porting of exportable data. Ask your cloud and platform providers how that applies to your contracts.
- Transfer assessment: If any acquirer staff outside the EEA can reach EU personal data in this account, remote access is a transfer under EDPB Guidelines 05/2021 and needs a Chapter V transfer tool.
Check with legal counsel whether your processor agreements and records of processing describe the database and access paths in enough detail to satisfy the documented-instructions requirement.
In a split setup, the target's systems and process data stay in the target's own region, while the harmonized engine or shared components serve the combined organization. This is the environment where the Chapter V question most often becomes concrete, because acquirer staff may need to view or administer target process instances that contain EU personal data. The architecture usually separates the engine instances by region and keeps the shared decision and reporting layer free of raw personal data where possible, but this design needs to be confirmed against the actual data flows.
- Per-region engines: Run one engine cluster per region with its own supported database, so timers, locks and running instances stay within the region that owns them.
- Shared rule and model repository: Keep BPMN models and DMN tables in a central repository only if they contain no personal data, and version them so each region can deploy the same rule version.
- Remote administration: Route acquirer administrators through a controlled access path, and log which staff accessed which regional instance, because remote access from a third country is a transfer.
- Transfer tooling: Where remote access from a non-EEA acquirer is needed, confirm with counsel which Chapter V transfer tool applies before access is granted.
- Processor instructions: Record each regional processing activity and any transfers in documented instructions, so the arrangement matches the controller's instructions under GDPR Article 28.
Before cutover, map every role that will touch target data and confirm its location and transfer basis in writing.
Which open-source engines fit a post-merger estate and why
Post-merger estates usually contain more than one process engine, and the choice between them is driven as much by license terms as by modeling features. The cards below cover the engines and integration tools most often weighed for harmonization, with the license fact and fit condition for each.
Flowable open source engine
Flowable provides BPMN, CMMN and DMN engines under Apache-2.0 with Java and REST APIs, so it can run approvals, case handling and decision tables on one platform. Version 8.0.0 was released on February 27, 2026 and moves to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3. Check whether the acquired company's Spring stack can move to that baseline before committing, and confirm the database types your data center supports, since the engine supports several SQL databases.
Camunda 8 for non-production use
Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. A merged estate can use it for modeling and testing during harmonization, but production cutover needs a commercial agreement or a different engine. Ask the vendor to confirm the license terms in writing, and map which of the two companies' existing Camunda processes would depend on production rights before the migration plan is fixed.
Node-RED for integration glue
Node-RED is licensed under Apache-2.0 and suits the connectors that bridge legacy approval systems, ERP queues and identity sources while both companies' processes run side by side. Its flow-based model is quick to change, but flows need the same version control, review and testing as code, or they become a second undocumented process layer. Confirm that the integration flows you need have maintained nodes for the target systems rather than custom ones your team must support.
n8n under Sustainable Use License
n8n is a fair-code platform under the Sustainable Use License, and files marked .ee require an n8n Enterprise License. Its license terms are narrower than Apache-2.0, so an integration layer built on it needs legal review before it is used across both legal entities or offered to a partner. Confirm which features your harmonization plan needs are outside the .ee files and whether internal use across the merged group fits the license without an additional agreement.
Operaton or a commercial suite
Operaton is named here as a comparison point to confirm, not a recommendation: it is a community fork of the Camunda 7 lineage, so confirm its license, release cadence and migration path for Camunda 7 processes directly with the project. A commercial BPM suite is the other comparison point, chosen when the merged company needs vendor support, low-code design tools or contractual SLAs that open-source options do not supply. Compare total cost, licensing per user or app, and exit terms before deciding.
How the harmonization rollout runs in phases
The sequence moves two companies' approval and operational processes onto one engine in controlled stages, so each phase produces evidence that the next phase depends on. Nothing is cut over until the migration, reconciliation and exit plan have been tested.
Inventory and map both process estates
Catalog every approval and operational process in both companies, including the legacy BPM suites, rule logic embedded in code, spreadsheets used as controls and the systems each process calls. Business process owners from each side validate the maps, and IT maps each process to the systems and data it touches. The step closes with a signed process inventory that marks each process as keep, merge, retire or undecided, along with the owner of each decision. Ask your partner to show how the inventory records which processes carry financial reporting, privacy or regulated-data obligations, because those drive the controls in later phases.
Define the target model and harmonize decisions
Design one target process model for each shared business capability, then reconcile the decision rules that the two companies apply to the same cases, such as approval limits, eligibility and routing. Rules are moved into versioned decision tables with named owners, so each decision can later be traced to the rule version that produced it. The output is an approved target model, a rule catalog with owners and a list of conflicts that business leaders have resolved in writing. Confirm with your partner how decision tables will be tested against historical cases from both companies before any rule goes live.
Pilot a low-risk process
Build the first process on the target engine and run it with a limited group of users, choosing a process with low financial and regulatory exposure, such as an internal request or a document approval. The pilot tests the engine configuration, identity integration, task forms, audit logging and the integrations the process depends on. The phase closes when the pilot has run through its test cases, the audit trail has been reviewed by the control owner and the lessons are recorded in the change log. Unresolved defects found here should block the next phase, not be carried forward.
Migrate running instances with reconciliation
Move in-flight process instances from the legacy suites to the target engine, which is the step where most merger projects lose track of work. For each migrated instance, the migration tooling records the source and target identifiers, the current task, the variables and the timers, and a reconciliation report compares counts and states on both sides. Cases that cannot be mapped cleanly are routed to a manual review queue owned by the business. Ask how the migration handles instances in mid-task, pending timers and open approvals, and how a failed batch is rolled back without losing audit history. The output is a reconciliation report signed by the business owner for each batch.
Cut over by business unit
Move each business unit to the target process model in sequence rather than switching the whole company at once. Before each cutover, the team confirms that new work is routed to the target engine, that legacy queues have been drained or migrated, and that support staff know the escalation path. Access rights are checked during the cutover so that users who changed roles during the merger do not keep approval authority they no longer hold. The cutover is complete when the legacy suite no longer receives new work for that unit and the unit's control evidence is generated from the target engine.
Test the exit plan before decommissioning
Before any legacy suite is switched off, the team tests the exit and transition plan for that system, including how data is exported, how audit records are retained and how a rollback to the legacy suite would work if a fault appears after cutover. Where the company is regulated, this test also confirms that the register of ICT services and the exit documentation match what is actually running. The phase closes with a tested exit report, archived legacy audit data that auditors can still read and a formal decommissioning approval from the control owner. Ask your partner which regulatory obligations it applies to this test and how the evidence is stored.
Integration points that carry the most risk after a merger
Which ERP and finance postings are most at risk when two companies merge their approval processes?
The highest risk is in the points where a BPMN process posts to the general ledger, creates purchase orders or triggers payments, because a mismatch there moves money and changes the books. Each posting pattern is usually a synchronous API call, a message queue, or a batch file drop, and the two legacy suites often use different ones. Map every posting step, its trigger, its idempotency handling and its retry behavior before migrating any running instance, so that an in-flight approval cannot post twice or not at all. Confirm with the finance systems owner which chart of accounts, cost centers and tax codes each business unit uses, and whether the acquired ERP will remain in service during the transition. Also confirm the period-close calendar, since a cutover during close creates reconciliation work. Public-company acquirers should ask how the excluded business is treated in internal control scoping, because the SEC allows exclusion of a newly acquired business from the first assessment for a limited period, with disclosure.
How should identity directories be connected when processes from two companies run on one engine?
Process engines rarely hold credentials themselves; they resolve users, groups and roles from a directory, so the main decision is which directory is authoritative for approval rights during the transition. Common patterns are federation of both directories into one identity provider, synchronization of group memberships into the engine's identity store, or a custom identity service that reads from LDAP or another source. Flowable documents that its identity management can be replaced by implementing its identity service interface, with an LDAP implementation provided as a reference, which makes a directory-backed approach workable but still needs design. Confirm with the identity owner how leavers from the acquired company are deprovisioned, since a stale approver account is a segregation-of-duties problem. Also confirm how delegation and out-of-office rules from each company will map, and whether the acquired staff will get accounts in the acquirer's directory before or after cutover.
What do document and records stores need from a process engine after a merger?
Approval processes usually reference contracts, invoices, signed forms and inspection records stored in document management systems, and the link between a task and its document must survive the move. The integration pattern is typically a document identifier stored as a process variable, with the file itself left in the source repository and retrieved through an API when a task opens. Avoid copying documents into process variables, since that bloats the engine database and spreads regulated content into places that were not designed for retention. Confirm with the records owner which retention schedules apply to each company's documents, whether legal hold can be applied to records referenced by active instances, and whether the acquired repository will be migrated or kept read-only. For EU personal data, confirm the processing purpose and which party acts as controller or processor, because GDPR Article 28 requires processors to act only on documented instructions.
How do customer and case systems connect to harmonized processes without breaking open cases?
Customer relationship systems, claims platforms and case tools hold the business state that processes act on, so the integration must keep one case identifier consistent across both companies. The usual pattern is an integration layer that exchanges events or calls APIs between the engine and the case system, with the engine holding only workflow state and references. Before cutover, decide whether open cases continue on the legacy system until closure, whether they are migrated with their history, or whether each carries a mapping to a new identifier. Confirm with the case system owner which fields are authoritative for status, owner and deadline, and how duplicate customer records from the two companies will be merged. Also confirm the contact-center and customer communication channels, because a change in case routing can change who a customer hears from. Customer data moving across borders during this work may also need a transfer basis, which the privacy owner should confirm.
Which reporting and data platforms must receive process data during a phased merger cutover?
Operational reports, management dashboards and regulatory extracts usually read from several sources at once, so a cutover that changes the process data model can silently break them. The usual pattern is to publish process events or periodic extracts from the engine's history tables into a staging area, then map them into the existing warehouse or reporting layer under a documented field mapping. Do not point reports directly at the engine's live database, since that couples reporting load and schema changes to production workflow. Confirm with the data owner which reports depend on status codes or timestamps that will change, how historical process data from the legacy suite will be combined with new engine data, and who signs off on report reconciliation for each business unit. If the platform is a data lake or warehouse run by the acquirer, confirm how lineage and ownership are recorded in the catalog so auditors can trace a reported figure back to its process instance.
Can a team handle these integration points internally, or does it need a partner?
Teams with strong integration engineering and a clear mapping of both legacy suites can often handle the individual integrations internally, particularly where the patterns are straightforward APIs or file exchanges. A partner adds the most value where several integrations must be sequenced around business unit cutovers, where the legacy suite's execution data must be reconciled with the new engine, or where the team has not run a production process engine before. The cost components are the discovery and mapping work, the build and test of each integration, the reconciliation effort during parallel running, and the ongoing operation of the engine and its connectors. Most of the cost is people time, and it is one-time for the migration but recurring for operation and support. Ask any partner to show a written scope listing each integration, its owner, its test approach and its exit criteria, since DeployOpen works from fixed, written scopes agreed before work begins. DeployOpen does not publish prices, so the quote follows from that scope.
Which evidence auditors and regulators will ask for
This table lists the evidence a merged organization typically needs to show during harmonization, the component that produces each item, and the rule or requirement that makes it relevant. Read it as a checklist to agree with your auditors early, since the list of required evidence depends on your sector, your listing status and your regulators. DeployOpen prepares the evidence, but auditors and certification bodies decide whether controls comply.
| Evidence item | Producing component | Why it matters in a merger |
|---|---|---|
| Register of ICT service arrangements | Vendor and service inventory maintained alongside the BPM platform deployment | DORA Article 28(3) expects a register covering all ICT service arrangements, including those inherited from the acquired company |
| Exit and transition plans | Documented migration runbooks and tested rollback steps for each business unit cutover | DORA Article 28(8) expects tested exit strategies for services supporting critical or important functions |
| Instance migration reconciliation reports | Scripted comparison of running process instances, variables and task assignments before and after migration | Shows that in-flight approvals from the acquired company were carried over without loss or duplication |
| Process version history | Versioned BPMN models in source control and the engine's deployment history | Lets assessors confirm which process definition governed each case during and after the transition |
| Decision rule version records | Versioned DMN tables with test results and deployment records | Shows which rule version decided a case, especially where harmonized policy replaced two different sets of rules |
| Engine change approvals | CI pipeline records, peer review approvals and promotion logs for the engine and models | Covers change approval and testing before production for the engine itself, which assessors review as IT general controls |
| Excluded acquired business disclosure | Management's documented scope decision and the list of excluded entities and processes | For SEC registrants, the SEC allows exclusion of a newly acquired business from ICFR assessment for a limited period, and the exclusion must be disclosed |
| Access and data transfer records | Engine identity mapping, access reviews and records of any remote access from non-EEA staff | Where an EU target's data is accessed from outside the EEA, a transfer tool is needed under Chapter V of the GDPR |
What to ask an implementation partner before signing
Start with the migration method, because it decides how much risk the merged company carries. Ask the partner how they map each legacy suite's process definitions, forms, variables and task assignments to the target engine, and whether running instances move in place, drain to completion, or are restarted. Ask how they reconcile instance counts and open tasks between source and target before and after each wave, who signs off the reconciliation, and what happens to an approval that was half complete when a cutover window closes. For Camunda 7 or Activiti processes moving to Flowable, ask for their written mapping of engine-specific features, and ask them to confirm which licensing applies to the target engine in production, since the Flowable open source page and the Camunda License 1.0 terms differ on production use. Ask for a sample of a migrated process with its test evidence before you agree on scope.
Next, test the access and exit controls. Ask how the partner restricts acquirer staff to the target data they need, including whether any remote access from outside the EEA is treated as a transfer that needs a transfer tool, and how that access is logged and reviewed. Ask how decision rule harmonization is tested: who signs off the DMN tables that replace each legacy rule, whether both rule sets are run side by side on historical cases, and how the tested version that decided each case is recorded. For the exit plan, ask for the transition and fallback design for each business unit, including how the legacy suite can be restored if a gate fails, and whether that plan is written against the requirements in the DORA exit strategy article if your group is a financial entity.
Finally, ask for the fixed-scope written deliverables and the cutover gate process. Request a list of the documents the partner will hand over, such as the process inventory, mapping specifications, migration runbooks, reconciliation reports, test results, rollback procedures and the updated register of processes and integrations. Ask who approves each cutover gate, whether that is your process owner, your security team or your compliance lead, and what evidence each approver receives before deciding. Confirm in writing whether the partner will support the first weeks after each business unit goes live, how changes during the freeze are handled, and what your organization must provide, such as legacy system access and business owner time. Ask for these answers in the statement of work, not only in a sales call.
How much effort, time and internal input does a merger BPM harmonization need?
What drives the cost and effort of harmonizing two companies' BPM processes?
The main drivers are the number of legacy BPM suites, the volume of running instances that must move, the number of decision rules to harmonize, the number of systems each process touches, the regulated scope and the number of business units that cut over. Each suite adds a mapping exercise, each running instance population adds a migration and reconciliation task, and each integration adds design, test and access work. Ask any partner to itemize these drivers in the quote so you can see which ones your merger actually triggers.
Which parts of a merger BPM harmonization are one-time and which recur?
The one-time work covers process inventory, mapping of legacy suites to a target engine, modeling of harmonized processes, migration of running instances, decision rule consolidation, integration build and cutover by business unit. Recurring costs cover operating the engine, applying security patches and version upgrades, monitoring, backups, support and any continuous retainer. Because the target engine remains in service after the merger closes, ask for the recurring operating model in writing alongside the one-time scope, including who patches the engine and who answers when a process fails at night.
How long does a merger BPM harmonization take?
DeployOpen does not quote a duration without a written scope, because the timeline depends on the number of suites, process variants, running instances, integrations and business units phased into cutover. The same suite can take weeks or many months depending on how many processes carry regulated approvals or long-running timers. Ask for a phased plan with milestones per business unit, the dependencies between phases and the points where your own owners must sign off before the next phase starts.
Can our internal team run a BPM harmonization without an implementation partner?
An internal team can do it if it already operates an open-source BPM engine, has developers who know the engine's Java or REST APIs and can dedicate people to inventory, testing and cutover for the full duration. The usual gaps are migration of running instances, which needs a tested reconciliation approach, and the engine operations model, which must stay running after the project ends. Assess your skills against each phase in the scope, and ask a partner to separate the parts they would deliver from the parts your team keeps.
What do process owners and compliance teams need to contribute?
Process owners must confirm the as-is steps, approval thresholds, exception paths and the business rules behind each decision, and they must accept the harmonized version for their unit. Compliance and internal control owners must confirm which approvals are control points, how segregation of duties applies and what audit evidence each process must retain. For regulated scope, the SEC's guidance on internal control over financial reporting also expects management to evaluate the IT general controls that support financial reporting risks, so involve the controls team early.
How does the Flowable licensing model affect the engagement effort?
Flowable's open source engines are licensed under Apache-2.0, and Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. That difference changes what you must budget for production use, so confirm the license terms for each engine before the scope is written. Ask the partner to state which licenses apply to each environment and which commercial products, if any, the design would depend on.
Does DeployOpen publish prices, and how is a quote produced?
DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. To compare proposals, ask each provider to list the suites, process count, running instances, decision rules, integrations, business units and regulated controls it assumed, plus the one-time and recurring items separately. Quotes that do not state these assumptions are hard to compare.
What should a scope document include to make a harmonization estimate reliable?
A usable scope lists every legacy suite and version, the inventory of processes and their owners, the count and state of running instances, the decision tables and their owners, the integrations with source and target systems, the business units and their cutover order, and the regulated controls to preserve. It also states acceptance criteria for migration and cutover and who approves each phase. Without these items, any duration or cost is an assumption, so request them before accepting a timeline.
How DeployOpen scopes and delivers a merger process harmonization
DeployOpen starts every merger harmonization with a fixed-scope written agreement that names the business units, process families, engines, integrations and cutover waves in scope. DeployOpen is a Chainscore Labs company, and its work covers planning, implementation, customization, integration, hardening, backup, upgrades, documentation and support of self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. Before any build starts, the first phase is an inventory: every BPM suite and engine in both companies, the deployed process definitions and versions, the count of running instances per definition, the decision tables, the forms and the external calls each process makes. That inventory decides whether a process is migrated, rebuilt or retired, and it is the document the steering group should sign off before the scope is priced against it.
Delivery then follows the same boundaries. Flowable and the surrounding services are installed in the client's infrastructure, and the target configuration, including the database type, identity source and the async executor settings used for clustered nodes, is recorded as part of the handover. DeployOpen runs security testing against the engine's REST and Java APIs and against each integration, and it prepares the evidence a compliance assessment will ask for, such as change records, access reviews for the process engine and decision version history. DeployOpen prepares that evidence but does not issue audit reports, attestations or certifications, so the reader should confirm with the external auditor which artifacts they accept before the first cutover wave. Ongoing upgrades, support and continuous testing are offered as retainers, which matters because the acquirer's engine version will keep moving after the merger closes.
