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 den meisten Fällen Microsoft 365 (Exchange Online) als gemeinsame Zielplattform. Entscheiden, ob in einen bestehenden Tenant migriert oder ein neuer aufgesetzt wird.
2. Postfächer analysieren
Anzahl, Größen, Shared Mailboxes, Verteiler, Ressourcenpostfächer und rechtliche Aufbewahrungspflichten erfassen. Große Postfächer und Archive bestimmen den Zeitplan.
3. Pilotmigration durchführen
Eine kleine, repräsentative Nutzergruppe migrieren und Mailfluss, Kalender-Freigaben und mobile Geräte prüfen.
4. Koexistenz einrichten
Über Mailrouting und Cross-Tenant-Sync sicherstellen, dass beide Seiten während derMigration nahtlos kommunizieren – inklusive einheitlicher globaler Adressliste und Frei/Gebucht-Kalenderinformation.
5. Vollständige Migration abschließen
Nutzer in Wellen umstellen, DNS/MX-Einträge kontrolliert umschalten und das Altsystem erst nach einer Nachlaufphase abschalten.
Zielmarke: keine verlorenen Nachrichten, keine Kalenderbrüche.
Kurz: Über eine geplante Koexistenz mit Wellen-Migration bleibt die Kommunikation durchgängig – der riskante „Big Bang" über Nacht ist im M&A-Kontext selten nötig.
Das ERP ist das komplexeste und riskanteste Integrationsobjekt – und selten das erste. Ziel ist eine an den Geschäftsanforderungen ausgerichtete Konsolidierung; eine vollständige Ablösung ist nicht immer nötig und in den ersten 100 Tagen fast nie sinnvoll. Das Vorgehen umfasst fünf Schritte:
1. ERP-Landschaften vergleichen
Beide Systeme (z. B. SAP, Microsoft Dynamics 365 Business Central) hinsichtlich Prozessabdeckung, Modulen, Individualisierungen und Betriebskosten gegenüberstellen.
2. Zielsystem definieren
Zwischen Konsolidierung auf ein System, selektiver Migration und temporärem Parallelbetrieb entscheiden.
Kriterium ist der Geschäftsnutzen, nicht die technische Vorliebe – die Entscheidung gehört ins Steering Committee.
3. Prozesse harmonisieren
Vor der technischen Migration die Geschäftsprozesse angleichen (Finanzbuchhaltung, Einkauf,Auftragsabwicklung). Uneinheitliche Prozesse sind die häufigste Ursache gescheiterter ERP-Zusammenführungen.
4. Stammdaten bereinigen
Kunden-, Lieferanten- und Artikelstammdaten deduplizieren und vereinheitlichen. Datenqualität entscheidet über den Migrationserfolg mehr als die Technik.
5. Migration durchführen
In klar abgegrenzten Wellen (modul- oder standortweise) migrieren, mit Testläufen unddefiniertem Rollback. Den Produktivstart auf einen geschäftsarmen Zeitpunkt legen, etwa den Monatsanfang nach Abschluss.
Kurz: Erst Prozesse und Stammdaten, dann Technik – und den ERP-Kern bewusst nach der Stabilisierungsphase angehen, nicht in den ersten 100 Tagen.
Nach einer Fusion ist das Sicherheitsniveau nur so hoch wie das der schwächeren Seite – zusammengeführte Netze vererben Schwachstellen.
Ziel ist eine gemeinsame Security-Baseline, bevor Systeme verbunden werden.
The procedure comprises five steps:
1. Sicherheitsniveau vergleichen
Beide Organisationen gegen einen gemeinsamen Referenzrahmen (z. B. ISO 27001, BSI IT-Grundschutz) bewerten und die Lücken priorisieren.
2. Richtlinien vereinheitlichen
Passwort-, Zugriffs-, Patch- und Endpoint-Richtlinien auf ein gemeinsames, jeweils höheres Niveau bringen.
3. IAM-Prozesse harmonisieren
Identitäten und Berechtigungen zusammenführen und Least Privilege durchsetzen – der häufigste Angriffsvektor direkt nach dem Closing.
4. Monitoring integrieren
Beide Umgebungen in ein gemeinsames SIEM/XDR (z. B. Microsoft Sentinel und Defender) einbinden, damit Vorfälle organisationsübergreifend sichtbar werden.
5. Schulungen durchführen
Mitarbeitende beider Seiten auf die gemeinsamen Standards schulen; Security-Awareness ist in der unsicheren Integrationsphase besonders relevant.
Kurz: Zuerst die gemeinsame Baseline und ein durchgängiges Monitoring, dann die technische Verbindung – nicht umgekehrt.
Wie Sie ein gemeinsames Sicherheitsniveau systematisch verankern.
Zwei Cloud-Landschaften bedeuten doppelte Kosten, uneinheitliche Sicherheit und intransparente Verantwortlichkeiten.
Ziel ist eine gemeinsame Governance über Kosten, Sicherheit und Architektur – nicht zwingend eine einzige Plattform.
The procedure comprises five steps:
1. Cloud-Assets erfassen
Alle Subscriptions, Tenants (z. B. Azure), SaaS-Dienste und deren Verträge inventarisieren. Schatten-IT und ungenutzte Ressourcen werden häufig erst hier sichtbar.
2. Sicherheitsrichtlinien angleichen
Eine einheitliche Baseline für Zugriff, Verschlüsselung, Logging und Compliance über beide Umgebungen festlegen.
3. Define target architecture
Entscheiden, welche Workloads konsolidiert, migriert oder parallel betrieben werden – anbieterneutral am Geschäftsbedarf ausgerichtet.
4. Identitäten konsolidieren
Cloud-Zugänge an das zusammengeführte Identitätsmodell (Entra ID) anbinden, mit einheitlicher MFA und Conditional Access.
5. Betrieb standardisieren
Gemeinsames Monitoring, FinOps-Kostenkontrolle und klare Verantwortlichkeiten etablieren.Zielmarke: Transparenz über 100 % der Cloud-Ausgaben und ein einheitliches Sicherheits-Reporting.
Kurz: Zuerst Transparenz und gemeinsame Governance, dann selektive Konsolidierung – Cloud-Synergien entstehen durch Steuerung, nicht durch Migration allein.
Datenmigration ist der Punkt, an dem Integrationsfehler irreversibel werden – verlorene oder falsch zugeordnete Daten lassen sich selten sauber rekonstruieren.
Ziel ist ein strukturierter, getesteter Prozess mit lückenloser Nachvollziehbarkeit. Das Vorgehen umfasst fünf Schritte:
1. Datenklassifizierung durchführen
Datenbestände nach Kritikalität, Schutzbedarf (DSGVO) und Aufbewahrungspflicht klassifizieren. Personenbezogene und regulierte Daten erhalten besondere Behandlung.
2. Zielsystem definieren
Festlegen, wohin welche Daten migriert werden, inklusive Format-, Struktur- undQualitätsanforderungen.
3. Migrationsstrategie festlegen
Zwischen Big-Bang und phasenweiser Migration entscheiden, mit klaren Cutover-Kriterien und einem Rollback-Plan.
4. Testmigration ausführen
Auf Basis einer repräsentativen Datenmenge Vollständigkeit, Korrektheit und Referenzintegrität prüfen, bevor produktive Daten bewegt werden.
5. Produktivmigration überwachen
Die Migration mit Validierungs- und Abgleichprotokollen begleiten und den Erfolg dokumentiert bestätigen. Zielmarke: nachweisbare Vollständigkeit über einen Quell-Ziel-Abgleich, ohne Datenverlust.
Kurz: Klassifizieren, testen, protokollieren – eine belegbare Vollständigkeit ist bei personenbezogenen Daten nicht nur Qualitäts-, sondern Compliance-Anforderung.
Integrationserfolg lässt sich über vier Dimensionen messen: Kosten (Synergien), Leistung (Betrieb und Fortschritt), Risiko (Sicherheit) und Akzeptanz (Nutzer).
Entscheidend ist die Baseline – Kennzahlen, die erst nach dem Closing definiert werden, lassen sich nicht mehr gegen den Ausgangszustand messen.
Sechs Kennzahlen haben sich bewährt:
1. Realisierte Synergien
Misst die tatsächlich gehobenen IT-Kostensynergien gegen den Business Case (Zielerreichung in %). Aussagekräftig nur mit sauberer Baseline vor dem Closing; erste Effekte stammen meist aus der Konsolidierung doppelter Lizenzen und M365-Tenants. Zielmarke: monatlicher Soll-Ist-Abgleich entlang des Business Case.
2. Systemkonsolidierungen
Anteil der im Integration Blueprint vorgesehenen Systemablösungen und -zusammenführungen,der tatsächlich umgesetzt ist (Konsolidierungsgrad). Zeigt, ob Doppelstrukturen abgebaut werden – oder nur auf dem Papier geplant sind.
3. Verfügbarkeit kritischer Systeme
Uptime der geschäftskritischen Systeme während und nach der Migration. Zielmarke: kein Absinken unter das vereinbarte SLA-Niveau (z. B. ≥ 99,5 % für Kernsysteme) – dieIntegration darf den laufenden Betrieb nie gefährden.
4. Migrationsfortschritt
Anteil der planmäßig abgeschlossenen Migrations- und Konsolidierungspakete gegen die Roadmap. Zielmarke: On-Time-Delivery der IT-Workstreams über 85 % nach 100 Tagen.
5. Sicherheitsvorfälle
Anzahl und Schwere sicherheitsrelevanter Incidents nach der Systemzusammenführung. Zielmarke: keine offenen kritischen (P1-)Risiken nach Tag 30 und keine durchIntegrationsfehler verursachten Vorfälle.
6. Nutzerzufriedenheit
Interner Integration-NPS aus Sicht der Mitarbeitenden – ein Frühindikator für Akzeptanz und Mitarbeiterbindung in der kritischen Phase. Zielmarke: über 50 Punkte nach Tag 60.
Kurz: Legen Sie diese Kennzahlen vor Day 1 fest, verankern Sie sie in einem Steuerungs-Dashboard und berichten Sie sie regelmäßig – nur so wird aus Reporting echte Steuerung. Wie Sie daraus ein Governance-Dashboard aufbauen, zeigt unser Leitfaden zum Governance-Modell.
Before the closing is after the closing.
Arrange initial consultation
In einem 30-minütigen Erstgespräch kläre ich gerne mit Ihnen zusammen, in welcher Phase Ihres Integrationsprozesses wir den größten Hebel haben – no sales pitch, no obligation.
Together we will find out if and how I can best support you.
Ich freue mich auf den Austausch mit Ihnen
