Why open source ITSM after a merger or acquisition needs its own plan
The acquired estate has to be discovered before it can be merged. On day one you usually have two service desks, two CMDBs or spreadsheets, and an unknown number of assets, licenses and contracts. The practical answer is to consolidate onto one self-hosted ITSM platform, but only after a discovery phase that inventories what actually exists. For most acquisitions, GLPI is the natural starting point because it covers tickets, assets, contracts and financial data in one product. iTop is the stronger choice when the CMDB model has to reflect complex service relationships across several business units. Choosing between them is a decision for the discovery findings, not for the first week of integration.
Acquisitions differ from steady-state ITSM because the timing is set by someone else's reporting calendar. The SEC allows management to exclude a newly acquired business from its assessment of internal control over financial reporting, but not beyond one year from the acquisition date and not from more than one annual report, and the exclusion and the business's significance must be disclosed. That window means the acquirer needs IT general control evidence for the acquired systems within a fixed period. Ask early which of the acquired systems support financial reporting, because SEC guidance only requires evaluation of the IT general controls that address financial reporting risks. The answer also depends on whether the target is a regulated entity, where its data sits, and whether the acquirer or the target falls under DORA or NIS2. Each of those changes the register, notification and exit requirements you must be able to meet from the first day of consolidation.
Which regulatory requirements shape an acquisition integration
This table lists the regulatory requirements that most often shape how an acquired IT estate is inventoried, merged and documented, with the build implication for the service desk and CMDB. Each row is a constraint to confirm with counsel and the external auditors, not a legal conclusion. Read the build implication column as the design question the requirement raises for your records.
| Requirement | What it asks for | Build implication |
|---|---|---|
| SEC ICFR new-acquisition exclusion | Management may exclude a newly acquired business from its internal control assessment, but not beyond one year from the acquisition date or from more than one annual report, and the exclusion and its significance must be disclosed. | Keep the acquired estate's asset, change and access records separable from day one so the exclusion scope and end date are provable. |
| SEC IT general control areas (Release 33-8810) | 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. | Map which acquired systems touch financial reporting, then make change tickets and access records for those systems the first consolidation priority. |
| SEC Form 8-K Item 1.05 incident disclosure | Material cybersecurity incidents must be disclosed generally within four business days after materiality is determined, and annual reports describe oversight of third-party service provider risk. | Ensure incident timestamps and affected-asset links exist for the acquired estate, so materiality can be assessed quickly during integration. |
| NIS2 Article 3(4) change notification | Entities report name, contact details, IP ranges, sector and service Member States to the competent authority, and notify changes without delay and within two weeks at most. | Track acquired legal entities, IP ranges and contacts in the CMDB with change dates so the two-week notification can be met. |
| DORA Article 28(3) register of ICT arrangements | Financial entities keep a register of all ICT service arrangements at entity, sub-consolidated and consolidated levels. | Model contracts and providers from both estates in one register, with a distinct entity field for each legal entity. |
| DORA Article 28(8) exit strategies | Tested exit strategies and transition plans are required for ICT services supporting critical or important functions. | Record dependencies and migration plans for acquired services as linked CMDB items, so transition plans can be tested against them. |
| EU Data Act switching rules | Data processing providers must support switching to another provider or on-premises infrastructure, with notice and transitional periods, data porting and no switching charges from 12 January 2027. | Confirm which acquired SaaS contracts fall under switching terms, and keep exportable data and export procedures in the contract register. |
| GDPR Article 28(3)(a) processor instructions | Processors act only on the controller's documented instructions, including for transfers, and processing records describe security measures where possible. | Document in writing which entity instructs each processor after the deal, and update the processing records when instructions change. |
| EDPB Guidelines 05/2021 remote access | Remote access to EU personal data from a third country, including for support or administration, counts as a transfer and needs a Chapter V transfer tool. | Restrict service desk and admin access from a non-EEA acquirer's staff to acquired EU systems by role, and log those sessions. |
| HIPAA 45 CFR 164.314(a) business associate terms | Business associate contracts require Security Rule compliance, flow-down to subcontractors handling ePHI, and reporting of security incidents to the covered entity. | Where acquired services handle ePHI, tag those assets and subcontractors in the CMDB and confirm each contract carries the flow-down terms. |
How to inventory an acquired estate you have not seen before
Start from the assumption that the acquired estate has no reliable inventory, and plan discovery as two parallel tracks: agent-based inventory on every device you can reach, and network discovery to find what has no agent. The agent track gives you hardware, installed software and identity of managed endpoints. The network track finds printers, network gear, unmanaged laptops, servers that were never enrolled and anything that answers on the target's address ranges. Neither track is complete alone, and the gap between their results is the first list you should work from. Ask the target's IT lead for their address plans, domain controllers, MDM tenant and any existing monitoring export before the first scan, and confirm the scan windows and credentials with the seller's team in writing.
GLPI Agent is the inventory component to evaluate for this work. According to the GLPI Agent documentation, it collects hardware and software inventory and sends it to GLPI, and it also performs network discovery and inventory, package deployment and remote ESX inventory. It runs on Windows, macOS and Linux, and it is the successor of FusionInventory Agent. Confirm with your own tests that the target's operating system versions, endpoint protection and privilege model allow the agent to run as intended. Unmanaged devices, shadow SaaS subscriptions and personal accounts used for work are not visible to either track, so reconcile them against the target's identity provider, expense and card data, and email domain records, and record each finding as an asset or a SaaS entry with an owner and a status.
Tag every discovered asset, account and contract with its legal entity from the first import, not after consolidation. Regulators and advisers will ask which entity owned or operated each system. For a US registrant, the SEC allows management to exclude a newly acquired business from its internal control assessment for a limited period, but the excluded business and its significance must be disclosed, so you need a defensible list of what belonged to the target on the acquisition date. For EU personal data, the same entity tags feed the processing records and the mapping of which controller or processor holds which data. Store the legal entity, acquisition date and source of each record as fields you can filter on, and keep the raw discovery exports unchanged so the mapping can be rebuilt if a finding is challenged.
GLPI or iTop: which platform fits which merger
An acquisition usually brings a second service desk, a second CMDB and a second identity directory. The platform choice depends on how deep the acquired estate's relationship mapping needs to go, which tools already exist on each side and whether the acquired business has customers who write in. The cards below set out where GLPI, iTop and the front-end helpdesks fit, and what to confirm before deciding.
GLPI as the consolidation core
GLPI covers tickets, asset management, CMDB, contracts and financial management in one GPL-3.0 application, which suits a merger where the priority is one inventory and one service desk across both estates. GLPI 12.0.0 was released on October 7, 2026. Check the host stack before planning: GLPI 12.0.0 requires PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Confirm whether the acquired directory can feed GLPI through LDAP or IMAP authentication while the parent identity stays authoritative.
iTop for complex relationship mapping
iTop is licensed under AGPL-3.0 and its CMDB model is customizable, so it fits an acquired estate with dense dependencies, such as business services that span both companies' applications, networks and hosting. Version 3.3.0 was published on September 15, 2026. The trade-off is design effort: the data model, classes and relationships must be agreed before bulk loading. Confirm how many relationship types the target estate needs and whether your team can maintain the model after go-live.
Zammad for a customer-facing acquired desk
Zammad is an AGPL-3.0 web helpdesk for customer support. It belongs in the design only where the acquired business answers customer or external requests through its own queue that must be kept during integration. It is not a replacement for the internal ITSM core. Confirm which channels the acquired desk uses, whether ticket history must migrate, and how its tickets link to the assets and services held in GLPI or iTop.
FreeScout as a lighter front end
FreeScout is an AGPL-3.0 helpdesk that suits a smaller acquired team handling shared mailboxes and simple customer conversations. Choose it when the requirement is a familiar mailbox-style queue rather than a full ITIL process model, and when the acquired business has no need for a separate change or problem workflow. Confirm the mailbox volume, the number of agents and whether it must link tickets to CMDB records through an integration you will build and maintain.
GLPI Network subscriptions as a cost reference
GLPI Network is the vendor subscription for GLPI, published with public cloud at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum. Self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), with level 3 support. Use these tiers only as a reference point in a comparison. Ask any quote to state which tier applies, what support covers and whether the agent and asset limits fit the combined estate.
Rollout phases for a day-one to steady-state merger integration
This sequence moves an acquired IT estate from unknown and unsupported on day one to a single, evidenced service desk and CMDB that finance, audit and third-party risk teams can rely on. Each phase closes with a named output that the next phase depends on.
Map legal entities and scope the estate
The acquirer's IT lead and the target's IT and finance leads agree which legal entities, business units, sites and systems are in scope, and who owns each one. Discovery runs first with agent-based inventory on endpoints and network discovery on server ranges, so unknown assets surface before anyone assumes what exists. The output is an entity map and an inventory baseline reviewed by both sides. The step is done when every discovered asset has an owning entity and an owner of record.
Stand up day-one support and escalation routing
Before any system is merged, the acquired users need a working path to get help. The team sets up a temporary intake channel, routes tickets to the existing desk, and defines severity levels, escalation contacts and out-of-hours coverage for the acquired staff. Security-relevant tickets are flagged for the incident process from the first day. The output is a published routing matrix and a tested escalation path, and the step closes when the first real tickets from the acquired population are routed and closed.
Reconcile contracts, licenses and support agreements
Finance, procurement and IT compare the target's software licenses, hardware maintenance, hosting and managed service contracts against the acquirer's register. Each contract is tagged with its entity, term, renewal and change-of-control terms, and overlapping licenses are identified for consolidation or early termination review. Where the target uses third-party providers that handle regulated data, the team records them in the supplier register. The output is a reconciled contract record in the ITSM tool, and the step is done when every contract has an owner and a renewal decision.
Define mapping rules for CMDB and ticket migration
Before moving any data, the team writes the rules that translate the target's asset classes, ticket categories, priorities, users and service names into the acquirer's model. The rules cover duplicate detection for devices and users, which system is the source of truth for each field, and what gets archived rather than migrated. A test migration runs in a non-production copy of the GLPI or iTop instance. The output is a signed-off mapping specification and a reconciliation report from the test run.
Migrate CMDB and tickets with a verified cutover
Before any version change or data load on the production instance, back up the database, the application files and the config directory, including glpi.key and glpicrypt.key, following the GLPI update procedure. Then load the target's CMDB and open tickets according to the mapping rules, run reconciliation counts against the source, and sample records for owner and entity accuracy. The output is a reconciliation log showing matched, unmatched and rejected records. The cutover is done when the counts match the signed-off report and the rollback point is documented.
Decommission the second service desk
Once the acquired users are working in the consolidated desk and open tickets are either closed or migrated, the team sets a read-only period for the old system, then retires its integrations, monitoring hooks and mailboxes. Retention obligations for the old tickets and logs are confirmed with legal and records owners before any data is deleted. The output is a decommissioning record listing each integration removed and where the archive lives. The step closes when no new tickets are created in the old desk and the archive is verified.
Hand over evidence for ICFR and third-party registers
The team packages the evidence the finance, audit and third-party risk teams need: the entity map, the reconciled asset and contract records, change and access records for the migration, and the decommissioning log. Where the acquired business is excluded from the ICFR assessment under SEC staff guidance, the team confirms with finance which systems fall under that exclusion and which must be covered. The output is an evidence package with a index and named owners. Independent auditors decide whether the evidence is sufficient, and the step is done when the owners accept the handover in writing.
Identity, monitoring and procurement links to plan before cutover
Before cutover, decide which identity source is authoritative for each user population and how the two directories relate. The GLPI user documentation describes authentication against the internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, tried in that order. Confirm that order in your own GLPI configuration, because a user who exists in both estates may authenticate against whichever source answers first. Map each acquired account to one identity record before any service desk user is migrated, and agree who owns the mapping for leavers, contractors and shared service accounts during the transition period. Confirm also how your directory federation handles group membership, since GLPI group-managed approval and assignment rules depend on it.
Monitoring and procurement feeds decide whether the merged CMDB reflects reality. Plan one feed from each monitoring system into CI records, keyed on a stable identifier such as hostname, serial number or agent-reported UUID, and confirm how duplicates are resolved when both estates report the same server under different names. Treat the acquired organization's procurement and contract system as the source of license truth, and reconcile GLPI contract and license records against it before any software true-up or renewal is assumed. Decide the change path for shared services such as the email gateway, VPN and directory, so that changes to those CIs go through one approval process in the merged desk and the acquired desk does not keep its own parallel change calendar.
Trust boundaries come before access grants. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, counts as a transfer. If acquirer staff outside the EEA need to view tickets, CI records or user data from an EU target, a Chapter V transfer tool must be in place before that access is granted, and the GDPR Article 28(3)(a) instructions from the controller must cover it. Record the data flows in the processing records, limit acquirer accounts to the scope the transfer tool covers, and confirm with counsel which tool applies. Build these checks into the cutover plan as hard gates rather than as follow-up tasks.
Evidence auditors and regulators ask for after a merger
This table maps the evidence an acquirer's auditors, regulators and internal control teams typically request after an acquisition, who asks for it, and which GLPI or audit log component produces it. Read each row as a question to answer before day one, not a finished record. The main takeaway is that the acquired estate must be tagged to legal entities and kept in one traceable history, because auditors test whether the records are complete and unaltered, while DeployOpen prepares the records and the auditor issues any opinion.
| Evidence | Who typically asks | Produced by and what to confirm |
|---|---|---|
| Asset register with legal-entity tags | Internal audit, ICFR assessors, DORA or NIS2 registers owners | GLPI assets with entity and location fields per acquired company. Confirm every acquired asset carries an owning legal entity before reporting. |
| Ticket and change history across both service desks | External auditors testing IT general controls, incident reviewers | GLPI tickets and change records, with the legacy desk's history imported or archived. Confirm timestamps and requester identities survive migration. |
| Reconciliation logs for licenses and contracts | Finance, procurement, software vendor audit teams | GLPI contracts and license records reconciled against discovered installations. Confirm the reconciliation date, method and sign-off are stored with the record. |
| Access logs and step-up authentication records for admin actions | Security assurance, ICFR assessors, regulators reviewing privileged access | GLPI session and authentication logs plus web server and database audit logs. Confirm log retention and that logs from both estates are collected centrally. |
| CMDB relationship records | Incident response leads, DORA and NIS2 reviewers, resilience testers | GLPI CMDB links between applications, services, assets and suppliers. Confirm relationships exist for the acquired applications that support critical functions. |
| Register of ICT arrangements and third-party services | Regulators under DORA Article 28, due diligence teams, the acquirer's board | GLPI supplier and contract records exported to the register format the regulator expects. Confirm the register covers acquired vendors and the acquirer's group level. |
| Migration and reconciliation exports | External auditors sampling the transition period | Exports and checksums from the source desks and CMDBs, plus the signed-off mapping of fields. Confirm which exports are retained and where. |
How much does it cost and how long does it take to merge two service desks?
What drives the cost of merging two service desks after an acquisition?
The cost is driven mainly by discovery scope, the number of assets and agents to roll out, how much CMDB modeling the combined estate needs, the volume of tickets and records to migrate, and the support subscription tier you choose. Discovery and agent rollout scale with the number of endpoints, including those in the acquired estate that nobody has inventoried. Migration effort scales with how messy the source data is. Software and support costs recur, while discovery, modeling, migration and cutover are largely one-time. For a reference point on subscriptions, the GLPI Network subscriptions page lists public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted plans from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). Ask any partner to show how their quote maps to each of these components.
How long does it take to consolidate two service desks and CMDBs?
The duration depends mainly on the size of the acquired estate, how many systems hold data that must move, and the deadlines your regulator or auditors set. Under SEC staff guidance, a newly acquired business can be excluded from management's internal control assessment, but not beyond one year from the acquisition date and not from more than one annual report, and the excluded business and its significance must be disclosed. That gives a public registrant an outer boundary for bringing the acquired IT estate under its controls. Regulated entities in the EU face their own clocks: NIS2 requires changes to registered details to be notified without delay and in any event within two weeks. Ask for a phased plan with a day-one scope, a consolidation scope and a decommissioning scope, each with its own dates agreed in writing.
What do we need to provide before a partner can scope the work?
Before scoping, the partner needs named asset owners for both estates, copies of the relevant contracts and license agreements, and administrator access to the identity systems that will sign users into the merged service desk. Asset owners confirm which devices, applications and sites belong to whom, which is often the fastest way to resolve unknown assets. Contract owners provide maintenance, license and third-party service terms so that renewals and overlaps can be reconciled. Identity administrators provide directory details, group structures and the authentication order you want, because GLPI supports internal database, LDAP, IMAP and other external authentication methods that are tried in a set order. Also supply a list of existing monitoring, procurement and HR feeds so integrations can be planned.
Can our internal IT team merge the service desks without an implementation partner?
Yes, a capable internal team can do parts of the work, but the skills and capacity needed should be checked honestly before committing. Internal staff usually know the business and the legacy systems best, which helps with mapping and reconciliation. The gaps tend to be in agent rollout across unmanaged endpoints, CMDB modeling that will survive future growth, secure migration of ticket and asset history, and cutover planning under a live day-one support process. A practical split is to keep ownership of business rules and approvals in-house while using an external team for the technical build and evidence. Whichever model you choose, confirm who will hold administrator credentials and how changes are recorded during the transition.
What should a fixed-scope quote for an ITSM merger include?
A fixed-scope quote should state the scope, deliverables, exclusions, timeline and acceptance criteria in writing before work starts. Ask for the list of systems in each estate, the discovery method and number of endpoints covered, the CMDB classes to be modeled, the data sets to migrate and the cutover approach. The quote should separate one-time work (discovery, modeling, migration, testing, cutover, documentation) from recurring items (software subscriptions, support tiers and any retainer for upgrades). It should also name the assumptions the price depends on, such as access windows, data quality and the number of decision makers. DeployOpen does not publish a price list, and a quote follows from the written scope.
Which compliance deadlines change the timing of an acquisition IT merger?
Deadlines depend on whether you are a public registrant, an EU financial or essential entity, or a healthcare provider, so confirm the applicable rules with your counsel and compliance team. Public registrants should map the acquired estate to their internal control scope within the permitted exclusion window. Under EU data rules, the GDPR requires processors to act only on documented instructions, and remote access to EU personal data from a third country is treated as a transfer, which can slow down access for a non-EEA acquirer's staff. Under the EU Data Act, providers must support switching and porting, which is relevant when moving data between platforms. Build these checkpoints into the plan rather than treating them as a final review.
Questions to ask an implementation partner before you sign
Start with discovery, because every later decision depends on how complete the asset picture is on day one. Ask the partner how they will find assets that the acquirer has never seen: which GLPI Agent deployment method they use for Windows, macOS and Linux endpoints, how they run network discovery across the acquired address ranges, and how they reconcile agent records with firewall logs, identity directories and cloud accounts. Ask what they do with devices that never check in, and who signs off on the unmatched list. A partner who cannot describe the reconciliation step in concrete terms is planning to discover assets by guesswork.
Next, ask how they separate legal entities and data before anything is merged. Request a written model showing how the acquired entity, its sites and its cost centers map to GLPI entities or iTop organizations, which roles can see which records, and how cross-entity visibility is limited during the transition. Ask how they handle EU personal data in the acquired estate, whether any non-EEA staff from the acquirer will remotely administer those systems (remote access from a third country can count as a transfer under EDPB Guidelines 05/2021), and which Chapter V transfer tool they would document. For DORA scope, ask how they will populate the register of ICT service arrangements under Article 28(3) and whether they have a tested exit strategy under Article 28(8) for any service supporting a critical or important function.
Finally, test the cutover plan. Ask whether the partner has a rehearsed rollback for the ticket and CMDB migration, meaning a documented database and file backup, the configuration keys such as glpi.key and glpicrypt.key that must be kept with any restore, and a timed restore on a copy of production. Ask how they migrate ticket history and CMDB change records, and whether closed tickets and asset histories will keep their original timestamps. Ask what the support subscription covers, including who applies security releases, how plugins are handled after an upgrade, and whether level 3 support is included. Request all of these answers in writing before you sign, since they determine what you can prove to an auditor later.
How DeployOpen scopes and runs a merger ITSM integration
An acquisition ITSM integration succeeds or fails on scope, discovery and the handover of ongoing support. DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside the client's own infrastructure. The cards below explain how that work is agreed, sequenced and evidenced.
Fixed-scope written agreement
Most engagements are fixed-scope, so the systems in play, the acquired entities covered, the deliverables and the timelines are agreed in writing before work starts. For a merger, the first question is which estate is in scope: the acquirer's GLPI or iTop instance, the target's service desk, or both. Ask the partner to state in the statement of work which environments are read-only during discovery, which accounts they will use and who approves any change to the target's production network. A quote follows from this written scope, so a vague scope produces a vague quote.
Discovery before migration
Discovery is the phase where the acquired estate is measured before anyone moves data. It covers the target's directories, hypervisors, endpoints, network ranges, service desk queues and existing CMDB, and produces a list of unknown assets and duplicate records. Confirm that discovery output is delivered as a reviewed inventory with owners assigned, not as a raw export. Agreeing the discovery deliverable in writing also sets the baseline for the later contract and license reconciliation.
Migration and cutover design
Migration covers moving tickets, assets, contacts, contracts and SLA definitions from the acquired desk into the target platform, with a cutover plan that defines what stops, what continues and who answers the phone on day one. The partner should document field mappings, deduplication rules and a rollback point for each batch. Ask how historical tickets are archived, since acquired records may carry retention obligations that the target's default settings do not meet.
Integration with the acquirer's identity and tools
Acquired staff usually need to sign in, raise tickets and receive notifications before their accounts are fully merged. DeployOpen implements the integration on the client's own infrastructure, so directory synchronization, mail notifications and monitoring feeds are built against the client's systems. GLPI supports authentication against its internal database, LDAP directories and IMAP mail servers, tried in that order, which lets a partner plan a staged identity cutover. Confirm the authentication order and fallback accounts before go-live.
Hardening, backup and handover
Before the integrated service desk takes live traffic, the platform should be hardened, backed up and documented. For GLPI, the update procedure requires backing up the database, the files and the config directory, including the glpi.key and glpicrypt.key files, which are needed to read encrypted data. Ask the partner to show a tested restore, the runbook for the acquired team and a named owner for each platform component after the engagement closes.
Retainers and compliance evidence
After cutover, many acquirers keep a retainer for upgrades, continuous testing and support while the combined estate is rationalized. Compliance work at DeployOpen prepares systems, controls and evidence for assessment, such as asset records, change tickets and access reviews, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Confirm which evidence the auditor expects, who collects it and how long the retainer runs before the scope is reopened.
