Post-merger project management consolidation | DeployOpen

Why open source project management after a merger starts with an inventory

After a merger or acquisition, the combined company often runs several project tools at once: a Jira instance from one side, a Redmine installation or Asana workspaces from the other, and spreadsheets filling the gaps. Delivery cannot pause while this is sorted out. The first step is an inventory of projects, workflows, users and data residency, and the platform choice follows from what that inventory shows. Without it, a team will pick a tool, discover that half the active projects use custom workflows it cannot reproduce, and start migrating with no fallback.

OpenProject and Plane are both credible targets for a consolidated instance, but neither is the answer before the inventory is done. OpenProject offers work packages, Gantt charts, agile boards and portfolio views, with Enterprise features such as SAML, OIDC and LDAP group synchronization listed on its pricing page. Plane has three self-hosted editions, and reaching paid features requires the Commercial Edition with a license key, so the edition decision depends on which single sign-on and directory features the merged organization must keep. Confirm which source systems you are moving, which versions they run, and whether each importer covers your deployment type. The OpenProject Jira Migrator, for example, supports Jira Data Center 10.x and 11.x but not Jira Cloud, and is documented as beta for test setups only. Plane's Jira importer covers Jira Cloud as well as Server and Data Center, but no importer covers every source, so treat each one as a candidate to test against your own data.

Which regulations and constraints shape a project data consolidation

This table lists the regulatory requirements most likely to affect moving project data from several Jira, Redmine or Asana instances into one platform, and what each one means for the migration plan. Read each row first against your entity's regulator and sector, because several rows apply only if the entity or its data falls in scope. The main takeaway is that the consolidation plan itself is a compliance artifact, so the inventory, access model and exit path need to be documented before cutover.

Requirement	Source	What it means for the build
ICFR exclusion for a newly acquired business	SEC ICFR FAQ, Question 3	Management may exclude the acquired business from its ICFR assessment only for a limited window, not beyond one year, and must disclose it. Plan the project data cutover so that any project records supporting financial reporting are controlled inside that window. Applies only to SEC registrants.
IT general control areas: program changes and access	SEC Release 33-8810	Program changes and access to programs and data are named IT general control areas. Map who can change workflows, custom fields and permissions during the migration, and keep an approval trail. Only relevant where project tools feed financial reporting controls.
Exit and transition plans for critical or important functions	DORA Article 28(8)	Financial entities must have tested exit strategies and transition plans for ICT services supporting critical or important functions. Treat the legacy Jira, Redmine or Asana instances as services that need a documented exit path and a rollback test. Applies only to DORA-regulated financial entities.
Switching duties and no switching charges from 12 January 2027	EU Data Act, Regulation (EU) 2023/2854	Providers must support switching and porting of exportable data, with no switching charges from 12 January 2027. Confirm export formats, notice periods and data return terms with each SaaS provider before planning the cutover. Applies to EU-relevant data processing services.
Documented instructions and processing records	GDPR Articles 28(3)(a) and 30	Processors act only on documented instructions, including for transfers, and records of processing should describe security measures. Write the consolidation as a documented instruction set, and update processing records for user, time-tracking and comment data moved into the new platform. Applies where personal data of EU data subjects is processed.
Remote access from a third country is a transfer	EDPB Guidelines 05/2021	Giving a non-EEA acquirer's staff remote access to an EU target's project systems, including for support, is a transfer that needs a Chapter V tool. Restrict migration administrator access by location and document the transfer basis before granting it. Applies to EU personal data.
Notification of changes to competent authority	NIS2 Directive, Article 3(4)	Essential and important entities must notify changes to registered details, such as contact details, IP ranges and sector, without delay and within two weeks. A new platform hostname, IP range or hosting location after consolidation can trigger this. Applies only if the entity is in scope of NIS2.
Business associate terms for ePHI in tickets	45 CFR 164.314(a)	If project tickets hold ePHI, the platform host and any subcontractor must be bound by a business associate contract requiring Security Rule compliance and incident reporting. Confirm that the target hosting partner signs these terms before any ePHI is migrated. Applies only to covered entities and business associates.

Which open-source platform fits a multi-instance merger

Consolidating several Jira, Redmine or Asana instances usually comes down to one question: which target platform can absorb the acquired data, users and workflows without breaking active delivery. The cards below compare the two candidates most often evaluated, the option to keep the existing Redmine estate, and the transition control that applies whichever platform you choose.

OpenProject as the consolidation target

OpenProject is licensed under GPL-3.0 and its Community edition is free, with work packages, Gantt charts, agile boards and dashboards. Single sign-on (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are Enterprise features, so a merged identity model usually means a paid per-user edition. The Jira Migrator only reads Jira Data Center 10.x and 11.x, not Jira Cloud, and it is in beta with documentation that advises test setups only. Confirm with the vendor whether your acquired Jira estate matches that scope before you plan the import.

Plane as the consolidation target

Plane Community Edition is licensed under AGPL-3.0, but moving a self-hosted install to a paid plan requires the Commercial Edition, which uses a license key and counts seats by paid roles. Its Jira importer runs on Plane Cloud and on all plans of the self-hosted Commercial Edition, and it covers Jira Cloud as well as Jira Server and Data Center. That makes Plane a candidate when your acquired estate is on Jira Cloud. Confirm which Jira fields, attachments and workflow states the importer maps, and how it handles Asana data, which is not in its documented scope.

Redmine where the estate already runs it

Redmine is the practical choice when one of the acquired instances already runs it, because its project hierarchy, roles and custom fields map directly to the target design. Teams should not assume that a Redmine data model fits a new platform without a mapping exercise. Confirm the import tooling, the export formats and the identity options against your own source data, including how user accounts, group memberships and plugin-based authentication will carry over. Plugin dependencies should be inventoried before any cutover date is set.

Read-only source instances during transition

Whichever platform you choose, the acquired source instances should stay available for reference but be locked to new edits once a project moves. Freezing each source at a defined cutover point keeps the migrated record consistent and preserves audit history for review. Agree with the acquired teams which instance is the system of record for each project during overlap, and confirm with the source vendor how read-only permissions, archived projects and attachments are handled. Keep an export of each source as a fallback until the target has passed reconciliation.

How the source system changes what can be moved

Jira Cloud is common in acquired companies that run a SaaS tenant. The supported route depends on the target. Plane's Jira importer supports Jira Cloud and is available on Plane Cloud and on all plans of the self-hosted Commercial Edition. The OpenProject Jira Migrator does not import from Jira Cloud. It reads Jira Data Center 10.x and 11.x, and its documentation advises using it only in test setups.

Importer coverage: Confirm which issue types, custom fields, components, versions and sprint data the Plane importer maps in the release you will deploy.
OpenProject route: Because the Migrator does not read Jira Cloud, any OpenProject path from Cloud needs a separate, tested transformation step that the implementation partner must scope.
Workflows and screens: Statuses, transitions, validators and screen layouts rarely map one to one and usually need to be rebuilt by hand in the target.
Groups and roles: Atlassian accounts, groups and project roles must be mapped to target roles and SSO identities before any import runs.
Attachments and history: Confirm whether comments, change history, issue links and attachments come across, and how large attachments are handled.

Ask the acquired team for the site URL, plan tier, installed Marketplace apps and a sample export, then run a test import on a copy of one project.

How user and permission mapping decides who can see what

Map every acquired role to a target role before the first import runs. Each acquired company arrives with its own names for project roles, its own groups and often its own directory, so the same person may be a project manager in one Jira instance and a viewer in another. The mapping sets two things at once: who can change delivery data after cutover, and whose actions appear in the audit trail. Build a table that lists each source role, its permissions, the target role it maps to and the named owner who approved it. Confirm how each source system exports users and groups, because deactivated accounts, shared service accounts and external contractors often need explicit decisions rather than automatic mapping.

On the target side, the identity design determines how far the mapping can be automated. OpenProject lists single sign-on over SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization, among its Enterprise features, so confirm with the vendor whether your directory group structure can drive project roles directly. Plane supports SAML and OIDC on its Pro plan and above, while LDAP support is listed as an Enterprise feature on self-hosted deployments. If the acquired entities run separate directories, decide early whether to keep them federated during the transition or consolidate them first, since that choice changes which edition you need before any data moves.

Access granted to the acquirer's own staff needs its own control. During integration, buyer teams often need to see target projects for due diligence, reporting or handover, and that access should be time-limited, tied to named individuals, and recorded in a written decision that states the scope and the end date. If any affected projects hold EU personal data and the acquirer's staff sit outside the EEA, remote access from a third country can count as a transfer, so legal review should happen before the account is created. Ask your implementation partner to show how each cross-entity account is provisioned, logged and removed.

How to phase the migration around active delivery

The sequence moves each source instance onto the target platform in controlled waves, so live projects keep delivering while every mapping, import and cutover is tested and signed off before the old systems are retired.

Inventory projects, workflows and risks
Catalog every Jira, Redmine or Asana instance, its projects, custom fields, workflows, integrations, active users and the regulatory or contractual obligations attached to each project. DeployOpen works with your project owners and administrators to classify each project by delivery risk, such as live client commitments, regulated records or work that cannot pause. The step closes with a project inventory and a risk register that names an owner for each high-risk item. Confirm importer edition requirements with the vendor early, because supported source versions differ by platform, for example Jira Cloud versus Jira Data Center.
Build the target and set up identity
Stand up the target platform in your own infrastructure, with the database, backups, TLS and the edition needed for the required single sign-on and directory sync. Connect the identity provider and agree the group structure that will drive roles across the merged organization. Confirm which features sit in the edition you buy, since SSO and LDAP are often gated behind paid tiers. The step is complete when a test environment passes an access review and a documented build record exists, covering versions, configuration and the backup and restore test result.
Map data and stage test imports
Build a mapping register that links each source status, issue type, custom field, role and user to its target equivalent, and records every field that cannot be carried over. Run imports into a staging environment using a copy of the source data, then compare counts, attachments, history, time entries and permissions against the source. Where importers are beta or limited, record the gaps and agree how they will be handled manually or archived. The step closes with a signed test report from the project owners that lists accepted losses and open defects.
Pilot with one or two business units
Move a small number of active projects from one or two business units to the target, with their teams working in the new system for a defined trial period agreed in advance. Track login issues, permission complaints, missing history and workflow friction in a shared log, and fix mapping rules in staging before any further import. Keep the source instance writable for these teams only until their projects are confirmed working. The step closes with a pilot acceptance record signed by each business unit lead and a list of changes made to the mapping.
Run production migration waves
Group the remaining projects into waves by business unit, dependency and risk, and schedule each wave around release dates and client milestones. For each wave, freeze the source projects, run a final incremental import, verify the results against the mapping register and reopen the target for the team. Write a cutover runbook per wave that covers the freeze, the import steps, the rollback path and the communication plan. The step is complete when each wave has a verification checklist signed by the project owners.
Make source instances read-only for retention
After the final wave, switch each source instance to read-only and keep it available for a retention period set by your legal, records and contractual obligations. Confirm with counsel and records managers whether any project data must be kept in a specific form, and export archives where the source cannot be retained in place. Remove user access that is no longer needed and document who can still read the archive. The step closes with a retention decision record and a tested method for retrieving archived data.
Decommission source instances and close out
Once the retention period ends and archives are verified, shut down the source instances, revoke integrations and service accounts, and remove stored credentials from the source hosts. Update the configuration management database, asset register and access reviews to reflect the retirement. Hand over the operating documentation, the mapping register and the lessons from each wave to the platform owners. The step is complete when a decommissioning record is signed and the target platform's support and upgrade plan is in place.

What auditors and regulators ask to see from the consolidation

This table maps the evidence an auditor, regulator or data protection authority typically asks for after a merger or acquisition moves project data onto one platform, what each item proves and which component produces it. Read it as a checklist to agree with your assessor before cutover, since the scope depends on whether the acquired business falls under ICFR, DORA, GDPR or HIPAA. DeployOpen prepares this evidence from the migration and platform configuration, but independent auditors and regulators decide whether it is sufficient.

Evidence	What it proves	Component that produces it
Migration inventory of projects, workflows and users	Every source Jira, Redmine or Asana instance was accounted for, with what was moved, merged, archived or retired	Source discovery report plus the migration register kept with the project plan
Change record for workflow and permission changes	Who approved each change to statuses, roles and project access, and when it took effect	Platform audit log and the change tickets linked to each configuration change
Access review of mapped groups	Users from the acquired company hold only the roles their new function needs, and leavers were removed	Directory group export from LDAP or SSO compared against the platform role mapping
Transfer assessment for cross-border access	Whether acquirer staff outside the EEA can reach EU personal data in the target's projects, and under which Chapter V tool	Data transfer impact assessment and the access list for administrators and support staff
Processor instructions and records of processing	The documented instructions under which DeployOpen and the hosting provider act, and how security measures are described	Signed statement of work, data processing terms and the updated record of processing activities
Exit and transition plan for DORA scope	A tested route to move project data away from the platform if it supports a critical or important function	Written exit strategy, migration runbook and the results of a restore or switching test
Retention of source data	Original Jira, Redmine or Asana data was preserved for the period your records policy or regulator requires	Archived export, read-only snapshot and the retention schedule signed off by legal

What does consolidating project management after a merger cost and require

What drives the cost of consolidating several project management instances?

The cost is driven mainly by the size of the inventory, the number of source instances, how complex their workflows are, and how well the target platform's importer fits the source data. Each source instance adds its own project inventory, custom fields, workflow states, permission schemes and attachment history that must be mapped and checked. Identity work matters as well: if the acquired company uses a different directory, every user, group and role needs a decision before data moves. Edition choice also changes the bill. OpenProject's Enterprise features include single sign-on and LDAP group synchronization, and Plane lists SAML and OIDC from its Pro plan and LDAP as an Enterprise feature, so the required identity features can determine which edition you license. Ask the partner to show how each driver was counted in the quote.

Which parts of consolidation are one-time and which costs recur?

One-time costs include the inventory, data mapping, migration runs, validation, user and permission mapping, configuration, and training. Recurring costs include software licenses, hosting, backups, monitoring, upgrades and support. For per-user editions, seat counts are the main recurring driver. OpenProject Enterprise on-premises is priced per named user per month, with Basic at 5.95 euros and Professional at 10.95 euros (25-user minimum), Premium at 15.95 euros (100-user minimum), and Corporate on request for 250 or more users, according to OpenProject's pricing page. Plane's Commercial Edition counts seats by users with paid roles, and its Business plan is listed at 13 to 15 US dollars per user per month on its pricing page for cloud use. Before signing, confirm which of these users are counted, including inactive or read-only accounts from the acquired company.

Can the internal team consolidate project management without outside help?

A capable internal team can often handle the inventory, stakeholder decisions and user communication, but the technical migration usually needs people who have run the target platform in production before. The hard parts are importer limits, mapping workflows that do not have a direct equivalent, and keeping active projects running during cutover. OpenProject's Jira Migrator, for example, imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and its documentation advises using it only in test setups while it is in beta. Plane's Jira importer supports Jira Cloud as well as Jira Server and Data Center. If the internal team lacks an engineer who has owned the target platform, a fixed-scope implementation with written deliverables is a common alternative. DeployOpen plans, implements, integrates and documents self-hosted platforms within the client's infrastructure, and most engagements are fixed-scope.

How long does consolidating project management take?

The duration depends on scope, not on a fixed template. The main variables are the number of source instances, the number of active projects that must keep running, the volume of attachments and history to move, how many workflows need redesign, and how many identity sources must be connected. Phasing around active delivery typically adds time because each wave needs its own validation and a rollback plan. No duration can be responsibly stated before the inventory is complete. Ask the partner to tie each phase to a written milestone, to name the assumptions behind the schedule, and to say which items would extend the timeline, such as an unsupported importer path or a late identity decision.

What does the acquirer's IT and PMO staff need to provide?

The work depends on decisions only the acquirer can make. IT needs to supply directory access, a decision on the identity source of truth, network and hosting constraints, backup and retention requirements, and an owner for the target platform after go-live. The PMO needs to confirm which projects are active, which are closing, which templates and reporting views leadership relies on, and who approves the target workflow design. Both teams should name one decision-maker for permission mapping, because access questions stall migrations more often than data questions do. If the acquired company falls under regulation, such as a SEC registrant that must assess internal control over financial reporting, the SEC staff FAQ allows excluding a newly acquired business from that assessment for a limited period, but the exclusion and its significance must be disclosed. Project records that support financial controls should be included in that review.

Can Jira project data move to a new platform without loss?

Not always, and the honest answer depends on the source edition and the target importer. Core elements such as projects, issues, many fields, and basic workflow states can often be mapped, but issue history, custom workflow logic, some permission schemes, Jira-specific links, and add-on data may need manual handling or may not transfer at all. OpenProject's Jira Migrator covers Jira Data Center 10.x and 11.x only, so Jira Cloud sources need another route. Plane's Jira importer supports Jira Cloud, Server and Data Center on its listed plans. Before accepting a migration plan, ask for a written field-by-field mapping, a list of items that will not transfer, a test migration on a copy of production data, and a reconciliation report comparing issue counts, attachments and assignees between source and target.

What should a written quote for consolidation include?

A usable quote lists the scope in writing before any work starts. It should state each source instance and the number of projects, issues and attachments in scope, the target edition and the seat count with the rule used to count them, and the identity integrations included. It should separate one-time work (inventory, mapping, migration waves, validation, training, cutover support) from recurring items (licenses, hosting, backups, support, upgrades). It should name exclusions, such as data cleanup, add-on replacement or custom reports, and state what happens if the inventory reveals more instances than planned. Ask how upgrades during the project are handled, what training is included, and who signs off each wave. DeployOpen does not publish a price list; a quote follows from the written scope.

What to ask an implementation partner before consolidating

Start with the inventory, because every other answer depends on it. Ask the partner to show, in writing, how the project list, workflow definitions, custom fields, permission schemes and integrations are extracted from each Jira, Redmine or Asana instance, and which of those objects the target platform can actually receive. Ask which importer versions were tested against your exact source versions. The OpenProject Jira migration documentation states that its Jira Migrator reads Jira Data Center 10.x and 11.x, not Jira Cloud, and is in beta with use advised only in test setups. A partner who cannot name the source product and version for each instance is not ready to scope the work. Also ask for a written list of what will be lost or flattened, such as history, attachments, workflow transitions, custom field types and cross-project links, with a decision owner for each item. Next, require sign-off on identity and access before any data moves. Ask for the user and group mapping table, showing how duplicate accounts from the acquired entity are matched, merged or deactivated, and who approves each exception. Ask how cross-entity access is limited during the transition: which groups can see projects from the other company, whether guest roles are used, and how external contractors are scoped. Ask who holds administrator rights on the consolidated instance and how those rights are recorded. Request the exit plan in writing as well: how data is exported in open formats, how long the source instances stay read-only, and what it would take to move the platform again. Under the EU Data Act, switching obligations apply to data processing services, so ask the partner to confirm in writing how those obligations are reflected in its own contract terms. Finally, settle the post-cutover obligations. Ask what training is included for project managers, administrators and the acquired teams, and whether it is delivered per role. Ask how upgrades will be handled after cutover: which release channel is used, how a test instance is kept current, who applies security updates, and what the notice period is for breaking changes. Confirm which edition is required for single sign-on, LDAP group sync and custom branding, because those features may sit in an Enterprise tier. Ask for each of these answers as a line item in the fixed-scope statement of work, so that acceptance can be measured against it.

How DeployOpen scopes and runs a project management consolidation

DeployOpen approaches consolidating project management after a merger or acquisition as a fixed-scope engagement, starting with a written inventory of every Jira, Redmine or Asana instance and the workflows, users and permissions they hold. The platform, migration waves and cutover plan are then built, tested and documented inside the client's own infrastructure.

How we scope

Inventory every Jira, Redmine or Asana instance, its projects, custom fields and workflows before choosing a target.
Record which importer paths apply, such as Jira Cloud versus Jira Data Center, and what each one cannot carry over.
Agree the written scope, deliverables and timeline with the client before any migration work starts.

How we build

Deploy the chosen open-source platform in the client's cloud account, data center or air-gapped network, with the agreed edition.
Map users, groups and permissions from each source system, and test single sign-on and directory sync against them.
Run trial migrations on copies of active projects, then verify task counts, history, attachments and access rules.

How we hand over

Document the target configuration, migration decisions, data exceptions and the cutover runbook for each wave.
Train project managers and administrators on the new workflows and on how archived source data is accessed.
Keep a record of who had access to which project data during the transition, to support the client's internal control and audit evidence.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if the client wants it.
Plan upgrades of the platform and its database on a schedule agreed with the client, not during active delivery peaks.
Confirm with the client which source instances are decommissioned, and in what order, once each wave is accepted.

Consolidating project management after a merger or acquisition

Why open source project management after a merger starts with an inventory

Which regulations and constraints shape a project data consolidation

Which open-source platform fits a multi-instance merger

OpenProject as the consolidation target

Plane as the consolidation target

Redmine where the estate already runs it

Read-only source instances during transition

How the source system changes what can be moved

How user and permission mapping decides who can see what

How to phase the migration around active delivery

Inventory projects, workflows and risks

Build the target and set up identity

Map data and stage test imports

Pilot with one or two business units

Run production migration waves

Make source instances read-only for retention

Decommission source instances and close out