Migration & Integration
ERP migration, hybrid cloud integration and master data work for German mid-market and enterprise teams — scoped around the constraints you actually carry.
Munich · Einsteinstr. 28
Scoping, not selling
Where the cutover actually happens: one port, one seam, one direction of flow
What makes an ERP migration late
Late migrations rarely fail on the cutover itself. They fail in the months before, when master data turns out to be inconsistent across systems, or when a downstream integration nobody documented stops working on the new platform. A second cause is scope that grew after the timeline was fixed: a department adds a workflow to the migration, and the testing window absorbs the cost. Inventorying the data and the interfaces before committing to a date is unglamorous, and it is the strongest predictor of staying on schedule.
The finance, procurement and inventory ledger that everything else reconciles against. Migration order matters here — the ERP's chart of accounts, cost centres and item master have to be frozen before any dependent system is loaded.
This is where customer master data tends to live in three places at once, with three different identifiers, and where a migration either resolves duplication or inherits it. The load order relative to the ERP decides whether the new ERP learns the customer once or three times.
Service management is usually the system that quietly leaks data into other tools. Discovery records, device ownership and licence entitlements all need a home on the new platform, or support tickets reopen against records that no longer exist.
Identity is the integration that decides who can reach what across your on-premise core and your cloud workloads. The design question is not whether cloud or on-premise wins on the whole estate — it is which identity source is authoritative for which system of record, and how a revocation propagates within the shift window.
Wikis, ticket queues and team workspaces pick up informal business logic no one wrote down. They migrate last, because they depend on the user directory from identity and on the ticket taxonomy from ITSM — and because nobody notices they broke until the first Monday after cutover.
Reporting workloads are the cleanest example of why data sovereignty is a per-workload decision, not a company-wide cloud policy. A marketing analytics dataset and an employee records system carry entirely different obligations, and treating them the same either over-restricts one or under-protects the other.
Master data is the part of a migration that cannot be rushed. If customer records exist in three systems with three different identifiers, the new ERP inherits the confusion unless someone resolves it first. We treat master data management as a defined stage, not a cleanup task squeezed between two milestones.
The four decisions we document, in order
Systems of record
For each domain — customer, item, vendor, employee — which system is the authoritative source. Written down, dated, and stored next to the migration plan.
Matching rules
How a record in one system is matched to its counterpart in another: exact key, fuzzy name, tax number, or a combination. The rule decides what counts as a duplicate.
Winner on conflict
When two systems disagree on a field — address, legal name, credit terms — which side wins and who signs that decision off. Conflict resolution without an owner becomes conflict resolution by accident.
Decision record
The documentation that becomes the reference when a discrepancy surfaces six months after cutover. Skipping this stage does not remove the work; it moves it to a worse moment.
The four-stage walkthrough
Discovery establishes what exists. Master data resolves who wins when systems disagree. Hybrid cut-over moves the workloads in waves across the cloud boundary. Data sovereignty decides the resting place of every dataset before the first byte moves.
Discovery · the system inventory and the unknowns
Stage by stage, in practice
Discovery is where the unknown integrations surface. Master data turns into a document, not a debate. Hybrid cut-over runs in waves with a rehearsed rollback position behind each one. Data sovereignty is decided workload by workload, with the buyer's legal and security teams in the room. The theatre above walks the four in order because that is the order they are decided in.
Our position
A marketing analytics dataset and an employee records system can carry entirely different obligations, and treating them the same either over-restricts the first or under-protects the second. We work through the constraints with the buyer's legal and security teams, then map each workload to a location and an access model. The output is a table, not a slogan, and it is what makes the architecture defensible in a review.
Hybrid cloud integration
They are running both, and the integration has to work across the boundary. Hybrid designs handle workloads with different residency constraints side by side, at the cost of more network complexity and a harder identity story. We build integration across that boundary, with explicit rules about which direction data may flow and where it may rest. A clear per-workload decision beats a company-wide cloud policy in almost every case we have seen.
Cloud-native integration patterns
Cloud-native integration changes how connectors are built and operated. Event-driven patterns replace nightly batch jobs, which shortens the window in which systems disagree with each other. The trade-off is that event-driven designs demand better error handling, because a failed event is silent unless someone built the alerting. Our integration software retries with backoff, routes failures to a review queue, and keeps a traceable history. In practice the operational discipline matters more than the pattern chosen.
What a failed event looks like when nobody built the alerting
Nothing on a dashboard. No ticket. No email. A record on one side that never reached the other side, discovered when a customer calls. Retry with backoff, a review queue, and a traceable history are what close that window.
Working with an implementation partner
German enterprise software buying is heavily influenced by implementation partners, for better and worse. A partner who knows the buyer's stack can compress a decision by months; one with a preferred vendor relationship can narrow the shortlist before the buyer notices. Sometimes we implement directly, sometimes we supply the integration layer and support a partner's team. We prefer the second when the partner owns the ERP relationship, because it keeps responsibility with whoever knows the platform best.
Testing and cutover discipline
A cutover plan that only covers the ERP leaves every downstream system untested until the morning it goes live. We run the integration paths in a staging environment against realistic volumes, including the failure cases, and we document the rollback position for each stage. Cutover weekends are long regardless. Having a rollback that has actually been rehearsed is what makes the difference when something unexpected appears at 3 a.m.
What to have ready before the first call
Bring the system inventory, the data owner for each domain, any regulatory constraint that touches where data may rest, and the deadline you are working toward. If the deadline came from the board rather than from the program, say so, because it changes what we propose. A scoping call with those four things in hand is far more useful than a feature demonstration. If you are earlier than that, our insights section covers the buying questions that come before a migration decision.
Read our compliance notesMunich · Monday to Friday, 09:00 – 18:00
TechPeak Solutions GmbH · we build the software, then stay for the cutover
