Post-merger IT integration
Remain capable of acting from day one
Related topics
What matters in IT system integration during a merger
After an acquisition, the first few months determine whether synergies become a reality – or whether technical debt will hold the new company back for years. We ensure that you make use of this window of opportunity, rather than losing it.
It's not technology that determines the success of integration, but the right plan at the right time.
Why it often goes wrong
The problem doesn't start at closing – it starts before.
Most IT integration problems are not technical problems. They arise because IT issues are involved too late in the M&A process, because no integration manager has been appointed, or because strategic decisions are postponed under time pressure – until they can no longer be avoided.
ERP access, cloud contracts, or shared infrastructure often continue via the seller – and are lost at closing.
Without a clear integration concept, both sides are working on parallel structures – and nobody knows whose architecture will win.
Which ERP system will we stick with? What is our cloud strategy? If these issues are left unresolved for too long, duplicate structures will emerge, which are costly to rectify.
Integrated systems mean integrated data – without proper governance, this can quickly become a regulatory issue.
Our approach
Four phases – a comprehensive integration approach
We don't just accompany you from milestone to milestone, but from start to finish. Each phase builds on the previous one – and delivers independently usable results.
01 | Pre-Closing
IT Due Diligence & Risk Assessment
We analyse the target company's IT landscape before closing: system architecture, contractual situations, technical debt, dependencies on the previous owner, and regulatory risks. The outcome is a clear basis for decision-making – not a status report.
02 | From signing to closing
Integration Blueprint
Together with your leadership team, we develop the target vision: Which systems will be consolidated, which replaced, and which operated in parallel temporarily? The blueprint creates clarity on priorities, dependencies, and resource requirements – before the first team begins to build.
03 | Closing ±4 weeks
Day-1-Readiness & Stabilisation
On the first day after closing, the new company must be operational – regardless of the extent of integration. We define the minimum operating framework, secure critical systems, and establish transitional operations that enable normal business alongside the integration project.
04 | Months 3-18 Post-Closing
System Consolidation & Handover
ERP, CRM, HR systems, infrastructure: We are integrating systems step-by-step, managing external service providers, coordinating data migration, and finally handing over a documented, stable IT environment to your internal IT organisation.
What you receive
Concrete results, no presentations
We deliver things that allow your organisation to continue working – not status reports that get filed away.
IT Risk Report (IT Due Diligence)
Structured assessment of the target company's IT landscape with prioritised action recommendations for the buyer and legal counsel.
Integration Blueprint
Target picture, decision matrix, system priorities and resource planning – as the basis for all subsequent implementation decisions.
Day-1-Playbook
Operationalised Plan for the First Week Post-Closing: Who does what, on which systems, with what access and escalation routes.
Handover documentation
Full documentation of the integrated IT environment: architecture, system responsibilities, contract overview, open points.
Why bitformer
What differentiates us from classic IT consulting
Strategy and implementation from a single source
We don't just design – we also implement. From IT due diligence and blueprinting to handover, one team is responsible for the entire process. No disconnect between strategy papers and operational reality, no finger-pointing between consultants and implementers.
Language for decision-makers rather than technical jargon
We translate IT complexity into decision-making bases that CFOs, supervisory boards, and shareholders can understand and utilise.
Early entry possible
We can get involved during the due diligence phase – and are therefore most useful where others have not yet begun.
Frequently Asked Questions
What customers most often ask us first
Where are you in the process right now?
Wherever you are at: In 30 minutes, we will jointly sort out what decision is next and where your greatest risk lies. No pitch, no commitment – just an honest assessment.
Good to know
How we work
The first 100 days determine whether the new company remains operational – not whether the integration is complete.
The aim is day-one operability with minimal risk; full consolidation will follow later. The priorities are business continuity, security and quickly visible synergies.
The procedure comprises five steps:
1. Define Day-1 Goals
Before closing, establish the minimum operating framework: which systems must be running on Day 1 (email, ERP access, network, identities) and which can wait until Week 4? A Day 1 playbook will detail who works on which system on Day 1, with what access rights and escalation paths.
2. Insure against critical risks
First, secure the vendor dependencies that will be terminated at closing – ERP access, cloud contracts, shared infrastructure – if necessary via a Transitional Service Agreement (TSA). The most acute security vulnerabilities (open domain trusts, orphaned access) will be addressed first; target: no open P1 risks after day 30.
3. Establish governance
Without clear decision-making structures, integrations fail due to unresolved responsibilities. Establish a steering committee with the CIO as a mandatory member, activate the IT PMO from Day 1, and assign decisions using a RACI matrix – this is what our detailed approach shows. Guide, how to structure a governance model.
4. Identify Quick Wins
Realise synergies that are low-risk and quickly visible: consolidation of duplicate licences and M365 tenants, merging of parallel tools, joint procurement. The ERP core consciously remains untouched in this phase – the risk-reward ratio there is unfavourable in the first 100 days.
5. Create integration roadmap
Translate the immediate measures into a robust roadmap for months 3 to 18 (ERP, CRM and HR consolidation, data migration), sequenced according to dependencies. A KPI dashboard makes progress measurable – for example, on-time delivery of IT workstreams from over 85 % to 100 days.
Briefly: In the first 100 days, you secure operations, address the most urgent risks, and establish the decision-making structure – full consolidation is deliberately a task for the subsequent phase.
Most integration projects fail not due to technology, but due to unclear responsibilities. A governance model defines who decides on what, how issues are escalated, and how progress is measured. The approach comprises five steps: 1. Define governance levels (Steering Committee, IT PMO, Workstreams) 2. Staff the Steering Committee – with the CIO as a mandatory member 3. Assign decisions clearly using a RACI matrix 4. Define escalation paths and meeting cadence 5. Govern with KPIs and refine after 30 days
our guide on how to set up a Steering Committee, IT-PMO, and decision-making pathways in detail Guide
The aim is a unified, secure identity model, without employees losing access to required resources.
Following an acquisition, there are usually two separate directories (Active Directory or Entra ID) with overlapping, sometimes orphaned accounts – creating both an attack surface and an operational risk.
The procedure comprises five steps:
1. Analyse of directory structures
Inventory both AD/Entra ID environments: domains, trusts, group policies, synchronisation. Flag orphaned accounts and excessive permissions first – they are the most common entry point immediately after closing.
2. Inventory permissions
Capture roles and access rights and assess them according to the principle of least privilege. Administrative accounts and service accounts first, as they carry the greatest risk.
3. Define target architecture
Decide between Merge (consolidation into one tenant), Coexistence (with cross-tenant sync), and Greenfield. For medium-sized businesses with a Microsoft stack, consolidation into a single Entra ID tenant is usually the goal; coexistence bridges the transition period.
4. Carry out test migration
Migrate a pilot group and check sign-in, resource access, MFA, and device compliance before productive accounts follow.
5. Implement rollout in stages
Migrate in groups, deactivate old accounts first rather than deleting them, and maintain a rollback window. Target objective: no unplanned access downtime for productive users.
In short: First, create transparency across both directories, then define a target architecture and migrate in groups – IAM consolidation is the foundation for all subsequent system and security integration.
E-mail is the system with the least fault tolerance – outages are immediately visible to everyone.
The goal is a phased migration with coexistence, ensuring communication and calendars function seamlessly across both organisations.
The procedure comprises five steps:
1. Define target platform
In most cases, Microsoft 365 (Exchange Online) as the common target platform. Decide whether to migrate to an existing tenant or set up a new one.
2. Analyse des Posteingangs
Capture the number, sizes, shared mailboxes, distribution lists, resource mailboxes, and legal retention requirements. Large mailboxes and archives will determine the schedule.
3. Perform pilot migration
Migrate a small, representative user group and check mail flow, calendar sharing, and mobile devices.
4. Setting up coexistence
Ensuring seamless communication between both sides during migration through mail routing and cross-tenant synchronisation – including a unified global address list and free/busy calendar information.
5. Complete the full migration
Switch users in waves, switch DNS/MX records in a controlled manner and only switch off the old system after a run-off phase.
Target: no lost messages, no calendar conflicts.
In brief: Through planned coexistence with wave migration, communication remains consistent – the risky „big bang" overnight is rarely necessary in an M&A context.
The ERP is the most complex and riskiest integration object – and rarely the first. The aim is consolidation aligned with business requirements; complete replacement isn't always necessary and is rarely sensible in the first 100 days. The approach comprises five steps:
1. Compare ERP landscapes
Both systems (e.g. SAP, Microsoft Dynamics 365 Business Central) to compare process coverage, modules, customisations, and operating costs.
2. Define the target system
Decide between consolidation onto one system, selective migration, and temporary parallel operation.
The criterion is business benefit, not technical preference – the decision belongs in the Steering Committee.
3. Harmonise processes
Align business processes (financial accounting, purchasing, order processing) before the technical migration. Inconsistent processes are the most common cause of failed ERP mergers.
4. Master data cleanup
Deduplicate and standardise customer, supplier, and article master data. Data quality determines the success of a migration more than the technology.
5. Carry out migration
Migrate in clearly defined waves (module or site-wise), with test runs and a defined rollback. Schedule the go-live for a low-business period, such as the beginning of the month after completion.
In brief: Processes and master data first, then technology – and tackle the ERP core consciously after the stabilisation phase, not in the first 100 days.
Following a merger, the security level is only as high as that of the weaker party – merged networks inherit vulnerabilities.
The goal is a common security baseline before systems are connected.
The procedure comprises five steps:
1. Compare security levels
Both organisations to assess against a common framework (e.g. ISO 27001, BSI IT-Grundschutz) and prioritise the gaps.
2. Standardise guidelines
Bring password, access, patch and endpoint policies to a common, higher level.
3. Harmonising IAM processes
Merging identities and permissions and enforcing least privilege – the most common attack vector immediately after closing.
4. Integrate monitoring
Integrate both environments into a common SIEM/XDR (e.g. Microsoft Sentinel and Defender) to provide cross-organisational visibility of incidents.
5. Conduct training
Train staff on both sides on the common standards; security awareness is particularly relevant during the insecure integration phase.
In short: First, a common baseline and consistent monitoring, then the technical connection – not the other way around.
Two cloud landscapes mean double the costs, inconsistent security, and unclear responsibilities.
The goal is joint governance over costs, security, and architecture – not necessarily a single platform.
The procedure comprises five steps:
1. Capture Cloud Assets
Inventory all subscriptions, tenants (e.g. Azure), SaaS services and their contracts. Shadow IT and unused resources often only become visible here.
2. Align security policies
Establish a unified baseline for access, encryption, logging, and compliance across both environments.
3. Define target architecture
Decide which workloads to consolidate, migrate, or run in parallel – vendor-neutral and aligned with business needs.
4. Consolidating identities
Connect cloud access to the unified identity model (Entra ID), with unified MFA and Conditional Access.
5. Standardise operation
Establish joint monitoring, FinOps cost control and clear lines of responsibility. Target: Transparency covering 100 % of cloud expenditure and standardised security reporting.
In short: Transparency and joint governance first, then selective consolidation – cloud synergies arise from control, not just migration.
Data migration is the point at which integration errors become irreversible – lost or incorrectly mapped data is rarely cleanly reconstructible.
The aim is a structured, tested process with complete traceability. The approach comprises five steps:
1. Perform data classification
Classify data sets by criticality, protection needs (GDPR) and retention obligations. Personal and regulated data will receive special treatment.
2. Define the target system
Defining where which data will be migrated, including format, structure, and quality requirements.
3. Define migration strategy
Between Big Bang and phased migration, decide with clear cutover criteria and a rollback plan.
4. Perform test migration
On the basis of a representative dataset, check completeness, correctness, and referential integrity before moving production data.
5. Monitor production migration
Accompany the migration with validation and reconciliation protocols, and confirm success with documented evidence. Target: demonstrable completeness through a source-target reconciliation, without data loss.
In short: Classify, test, log – demonstrable completeness of personal data is not just a quality requirement, but a compliance one.
Integration success can be measured across four dimensions: cost (synergies), performance (operations and progress), risk (security), and acceptance (users).
The baseline is crucial – metrics defined only after closing cannot be measured against the initial state.
Six key figures have proven themselves:
Realised synergies
Measures the IT cost synergies actually realised against the business case (target achievement in %). Only meaningful with a clean baseline prior to closing; initial effects usually stem from the consolidation of duplicate licences and M365 tenants. Target: monthly target-actual comparison against the business case.
2. System consolidations
Proportion of system deconsolidations and consolidations planned in the Integration Blueprint that has actually been implemented (degree of consolidation). Shows whether duplicate structures are being dismantled or are only planned on paper.
3. Availability of critical systems
Uptime of business-critical systems during and after the migration. Target: no drop below the agreed SLA level (e.g. ≥ 99.5 % for core systems) – the integration must never jeopardise ongoing operations.
4. Migration Progress
Proportion of migration and consolidation packages completed on schedule against the roadmap. Target: On-time delivery of IT workstreams exceeding 85 % after 100 days.
5. Security Incidents
Number and severity of security-relevant incidents after system merge. Target: no open critical (P1) risks after Day 30 and no incidents caused by integration errors.
6. User satisfaction
Internal Integration NPS from the employee's perspective – an early indicator of acceptance and employee retention in the critical phase. Target: over 50 points after day 60.
In short: Define these key figures before Day 1, anchor them in a control dashboard and report them regularly – this is the only way reporting becomes real control. How to build a governance dashboard from this is shown by our Guidance on the governance model.
Before the closing is after the closing.
Arrange initial consultation
In an initial 30-minute consultation, I would be happy to discuss with you which phase of your integration process offers the greatest leverage – no sales pitch, no obligation.
Together we will find out if and how I can best support you.
I look forward to exchanging with you
