Data integration: one shared data base instead of many lists
Customer addresses in the order system, contacts in a spreadsheet, prices in a document on the file share, agreements in a mailbox: we bring these records together, clear duplicates, standardise master data and define who maintains which field.
Entry point and delivery · net plus VAT
- A survey before any consolidation, so the scope is known
- Fixed price per data source instead of an open estimate
- Cleansing and ownership rules belong in the project, not after it
- A named contact and ongoing care beyond the rollout
The data review starts at 1,900 € net and covers a survey of your data sources, a duplicate check across the existing records, a written report and a prioritised list of measures. Consolidating one source starts at 4,900 € net as a fixed price that is set after the review. Ongoing care of the data base starts at 190 € net per month. All prices net plus VAT; third-party licences and fees are shown separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
In companies that have grown over time, the same information sits in several places: the customer is in the order system, their contact person in a sales spreadsheet, their bank details in the accounting software and the agreement from the last project in a mailbox. Each of these sources made sense when it was created, and none of them is complete. Data integration therefore does not mean forcing everything into a single program. It means deciding, for every piece of information, where it originates, who maintains it and where it is distributed — and merging the existing records so that a question has one answer rather than four.
Four versions become one maintained set of records
How one list turns into four versions of the truth
The path there is rarely a bad decision; it is a chain of small, individually sensible steps. The order system cannot hold contacts with responsibilities, so the sales team starts its own list. Accounting needs separate invoice addresses, so it maintains its own version of the customer record. Service wants to know which device is installed where and begins a third register. After a few years all three records are in use, all three are partly maintained, and nobody can say which one is right. The effort is invisible at first because it is spread across many short searches. It only becomes obvious when a report is due or when a colleague leaves and takes their knowledge of the lists with them.
Four answers to one question
How many active customers does the company have? Depending on who is asked and which list is opened, the figures differ — and none of them can be substantiated.
Searching instead of working
Before anyone can answer a query, two programs and a file share are opened. A single lookup takes minutes; added up, it is a noticeable part of the working day.
Post comes back
Address changes reach one source but not the others. Invoices go to outdated addresses, reminders to former contacts, quotations to sites that have closed.
Reporting takes days
Every figure requires exports, manual merging and reconciliation. By the time the result is ready, the period it describes is long over.
What data integration actually involves
Data integration is craft work, not a tool purchase. The larger part of the effort goes into understanding the existing records: which sources really exist, which fields mean the same thing despite different names, and which entries describe the same customer in three spellings. Only then comes the technical consolidation, which by comparison is usually unspectacular. We work through the following six building blocks in almost every project, in this order and with different weighting depending on the starting position.
Survey the sources
We record which programs, spreadsheets, mailboxes and folders hold data today — including those that are officially retired but still opened in daily work. For each source we note volume, currency and who uses it.
Define the data model
Customer, site, contact, asset, order: we clarify what these terms really mean in your business, how they relate and which fields a shared base has to carry. The model comes from your workflows, not from a template.
Detect duplicates
Using comparison rules across name, address, tax number, phone number and postcode, we find entries that describe the same thing. Borderline cases are not decided automatically but put forward for review.
Ownership per field
For every important field we define which system leads and which department maintains it. That definition is written down in the process documentation and stays traceable after staff changes.
Migrate historic data
Past transactions, documents and histories are carried over as far as daily work or retention periods require. What is migrated and what goes into the archive is your decision, based on a clear breakdown.
Make the data reportable
Only once terms and keys are consistent can figures be pulled without manual work. A shared base is therefore the precondition for metrics and reporting.
Detecting and merging duplicates
Duplicates are not created by carelessness but by haste: the caller cannot be found because the company name is spelled differently, so a new record is created. After a few years a single customer has several entries, each holding part of the history. We work through these records with several comparison rules and use graded matches rather than a single yes-or-no decision. Unambiguous cases are merged, uncertain ones go onto a review list that your department can work through in manageable steps. The original records are backed up before any merge, and every merge is logged so it stays traceable and, if necessary, reversible.
- Company names written with the legal form abbreviated, spelled out or omitted entirely
- Umlauts and special characters that were mangled by an import in another encoding
- Addresses with different spellings of street, house number and additional line
- Former contacts still listed as active people
- Sites of the same company recorded as separate customers
- Test records left over from the rollout of earlier programs
Cleansing belongs in the project, not after it
Standardising master data
Standardisation sounds like a formality and in practice decides whether a shared base holds. If one program keeps customer numbers with leading zeros and another without, the records will not line up. If units of measure are spelled out in one place and abbreviated in another, nothing can be totalled. We therefore agree a binding format for every shared field: number ranges, date formats, units, country codes, phone numbers in a consistent notation and a list of permitted values for selection fields. These rules are not only documented but checked on entry and on import, so the cleaned state does not dissolve again within a few months.
One key that ties the systems together
For two systems to talk about the same customer, they need a shared key. As a rule one system issues the numbers and the others store that number as a reference. Where an older program allows no additional field, we work with a mapping table in the intermediate layer. Reconciliation then runs through the interfaces without anyone comparing numbers by hand.
- Starting point: every system has its own number for the same customer
- Approach: pick the leading system, add a reference field or a mapping table
- Outcome: transactions can be tied to the same customer file across systems
| Customer file | Inventory system | Reconciliation |
|---|---|---|
| Customer A | K-10428 | matched |
| Customer B | K-10429 | matched |
| Customer C | K-10430 | to clarify |
Ownership per field: who maintains what
The most common reason a cleaned data base drifts apart again is unclear ownership. As long as three departments may change the same address and none of them knows which change will prevail, new discrepancies appear faster than they can be cleared. We therefore work with you on an overview that answers three questions for every important field: which system holds the value, which role may change it, and which systems receive it. The result is not bureaucracy but a single page that is handed over during onboarding and settles the argument when one arises.
| Data field | Leading system | Maintained by | Distributed to |
|---|---|---|---|
| Customer record with address and tax number | Order system | Order intake | Accounting, dispatch, reporting |
| Contacts and phone numbers | Contact management | Sales and inside sales | Order system, service planning |
| Product and service catalogue | Inventory system | Purchasing | Quotation, costing, invoice |
| Prices and conditions | Inventory system | Commercial management | Quotation, order, invoice |
| Payment status | Accounting software | Accounting | Order system, dunning |
| Project and service history | Service planning | Technical and dispatch teams | Customer file, reporting |
Migrating historic data
How much history comes along determines both effort and acceptance. Migrate too little and the departments keep working in the old lists while the new base stays empty. Migrate everything unchecked and twenty years of disorder move into a new system. We therefore separate by use: whatever is needed in daily work is migrated in full and cleaned. Whatever is only needed as evidence or for retention periods goes into a readable, searchable archive. Whatever meets neither criterion is discarded once you have approved it. We discuss this split before the migration on the basis of a concrete breakdown, not afterwards.
Survey of the data sources
We speak with the people who work with the data every day and look at the sources: programs, spreadsheets, folders on the file share, mailboxes and forms. The result is an overview of where each piece of information originates, how often it changes and who needs it.
Field mapping and data model
For every source we map the fields to one another and name the differences: diverging labels, different formats, fields with no counterpart. From this comes the shared model, containing the fields that are genuinely used.
Duplicate check and cleansing
The records are checked with graded comparison rules. Unambiguous duplicates are merged, uncertain cases go onto a review list for your department. The original records are backed up beforehand and every merge is logged.
Ownership and maintenance rules
For each field we record which system leads, which role may change it and where it is distributed. Format rules and permitted values are added and checked on entry and import, so the cleaned state holds.
Migration and reconciliation
The data is moved into the shared base and reconciled through interfaces with the systems that stay in use. Read-only at first, then writing, each step with a comparison between old and new.
Retiring side lists and ongoing checks
Only once the shared base holds in daily work are the old lists set to read-only and then retired. A regular check for new duplicates, gaps and format deviations is part of ongoing care.
We speak with the people who work with the data every day and look at the sources: programs, spreadsheets, folders on the file share, mailboxes and forms. The result is an overview of where each piece of information originates, how often it changes and who needs it.
For every source we map the fields to one another and name the differences: diverging labels, different formats, fields with no counterpart. From this comes the shared model, containing the fields that are genuinely used.
The records are checked with graded comparison rules. Unambiguous duplicates are merged, uncertain cases go onto a review list for your department. The original records are backed up beforehand and every merge is logged.
For each field we record which system leads, which role may change it and where it is distributed. Format rules and permitted values are added and checked on entry and import, so the cleaned state holds.
The data is moved into the shared base and reconciled through interfaces with the systems that stay in use. Read-only at first, then writing, each step with a comparison between old and new.
Only once the shared base holds in daily work are the old lists set to read-only and then retired. A regular check for new duplicates, gaps and format deviations is part of ongoing care.
Data quality is the precondition for any reporting
Many reporting projects fail not on presentation but on the foundation. A report showing revenue per customer is worthless if one customer is held under three numbers. A capacity overview misleads if hours are recorded in two systems with different definitions. That is why data integration comes before building metrics with us, not alongside them. Once terms, keys and responsibilities are settled, figures can be pulled automatically instead of being collected by hand each month — and the discussion in the management meeting turns on the decision rather than on which number is correct. The share of companies in Germany that link operational workflows through software has been growing steadily for years (Federal Statistical Office).
since 2013
experience with business IT
50+
delivered projects (project experience)
3-8 weeks
typical duration per stage (project experience)
1
leading source per data field
Three routes to a shared data base
Scattered records can be brought together in different ways. Which route fits depends on the number of sources, the data volume and how much disruption to operations is acceptable.
Force everything into one system
- Included: In the end there really is only one program left
- Included: No further reconciliation between systems is needed
- Not included: Departmental specifics are often lost along the way
- Not included: High effort and a long wait before the first visible benefit
- Not included: The switch hits every area at the same time
Keep the lists and reconcile them
- Included: Nobody has to change their familiar way of working
- Included: No project cost at the outset
- Not included: Reconciliation stays manual and is never complete
- Not included: Every report starts the merging exercise from scratch
- Not included: Knowledge about the lists rests with individual people
Shared base with clear ownership
- Included: Proven specialist programs stay where they are strong
- Included: One leading system per field, distributed automatically to the others
- Included: Cleansing and ownership rules are part of the delivery
- Included: Side lists are retired gradually instead of on a cut-over date
- Not included: The reconciliation path has to be operated and monitored
Typical starting positions in mid-sized companies
Illustrative scenarios from typical project journeys (project experience), anonymised and without client details.
What data integration costs
Prices for bringing your data together
All prices net plus VAT. Every project starts with a data review; the binding fixed price for delivery is set afterwards.
Data review
The entry point: we look at which sources exist and what condition they are in.
- Survey of every data source in the business
- Field mapping and a draft of the shared model
- Duplicate check across the existing records
- Written report with a cleansing plan
- Prioritised list of measures with effort ranges
Consolidation per source
One data source is cleaned, migrated and kept reconciled.
- Cleansing and merging of duplicates
- Standardisation of formats and keys
- Migration of historic data as agreed
- Reconciliation via interface or governed file exchange
- A fixed price that is set after the review
Ongoing care
So the cleaned base still holds two years from now.
- Regular checks for new duplicates and gaps
- Monitoring of the reconciliation paths with alerting
- Adjusting the rules when workflows change
- A contact for questions from the departments
- Adding further sources as required
All prices net plus VAT. Third-party licences and fees are shown separately from the fixed price. The full breakdown is on the pricing overview.
Not sure how many sources really exist in your business?
That is exactly what the data review answers. We speak with the departments, survey the sources and put a breakdown in front of you that shows the scope and a sensible order of work — before anything is merged.