Enterprise integration map: how to document systems, flows and owners before modernising your stack

Before modernising any integration stack there is a question many companies cannot answer precisely: which systems are connected to each other, with what data, and who is responsible for each connection? Without that map, any modernisation project starts with incomplete information, and that translates into surprises during implementation.

This article explains how to build an enterprise integration map: what to document, at what level of detail, how to obtain the information and how to use it to prioritise before taking on a migration.

Quick summary

• The map is not technical documentation: it is a decision tool for prioritising and estimating.
• The most valuable information is not in the code, it is in the teams that operate each system.
• An incomplete but real map is worth more than an exhaustive one that is never finished.
• There is almost always at least one active integration nobody remembered, and that finding justifies the exercise on its own.

Why document before modernising

It is common for existing integrations to have been built at different times, by different teams or suppliers, with no centralised record of how they work. The knowledge ends up living in the heads of one or two people. Modernising on that basis is like renovating a house without the plans: it can be done, but the risk of breaking something you could not see is high.

The map serves three concrete purposes:

• Sizing the project. Without knowing how many flows exist, any effort estimate is a made-up number.
• Prioritising. It makes it possible to decide what to migrate first according to criticality and fragility, instead of by order of discovery.
• Reducing the risk of omission. An integration left out of scope through ignorance shows up in production, at the worst possible moment.

What an integration map should include

Field	What to record	Why it matters
Systems involved	Origin and destination of each flow	Defines the real scope
Data exchanged	What information travels and in which direction	Determines the rules to replicate
Frequency and mode	Real time, batch, manual	Conditions the target architecture
Transformation rules	Mappings, conversions, default values	It is what gets lost most in a migration
Technical owner	Who maintains it today	Defines who to consult
Business owner	Who suffers if it fails	Defines who validates
Dependencies	Which processes stop if it fails	Determines criticality
Known errors	Identified recurring failures	Avoids reproducing them
Volume	Transactions per day or month	Conditions the sizing
Criticality	High, medium, low	Orders the migration

The two fields that are most often missing and add the most value are the transformation rules and the business owner. The first because it is what gets lost in a rushed migration; the second because without it there is nobody who can confirm the migration went well.

How to build the map in practice

The map does not have to start out perfect. A method that works:

1. Inventory of systems. List every platform that takes part in the data exchange: ERP, ecommerce, CRM, POS, OMS, WMS, payment gateways, invoicing, logistics, marketing tools. Also include shared spreadsheets and manual processes: they are integrations, even if they do not look like it.

2. Interviews per team. Talk to the people who operate each system, not just to IT. Also to operations, finance and customer support. Two questions organise almost the whole conversation: what information do you need to arrive from another system in order to do your job, and what happens when that information does not arrive or arrives wrong.

3. Technical review. Contrast what was reported with reality: which connections actually exist, which credentials are active, which scheduled processes run and how often. This is where forgotten integrations usually appear.

4. Record of business rules. For each flow, document the transformations and exceptions. It is the most tedious part and the most valuable.

5. Classification. Assign criticality and fragility to each integration. The combination of both defines the order of work.

6. Validation. Return the map to the interviewed teams so they can confirm or correct it. What is not validated is not trustworthy.

How to use the map to prioritise

With the map complete, prioritisation stops being a discussion of opinions. A criticality and fragility matrix organises the work:

	Low fragility	High fragility
High criticality	Monitor and document	Top migration priority
Low criticality	Leave for last	Good candidates to migrate first as a pilot

The critical and fragile integrations are the real urgency. The low-criticality, fragile ones are excellent candidates for validating the migration approach with low risk, exactly as set out when migrating from point-to-point to a centralised platform. The usual destination for that map is a central layer such as Weavee’s Universal Connection, which brings the flows together in a single hub with monitoring and per-transaction traceability.

Common errors when building the map

• Seeking exhaustiveness before usefulness. A map that takes six months to be perfect arrives too late for the decision it was meant to inform.
• Documenting only the technical side. Without the business impact, the map is no use for prioritising.
• Ignoring manual processes. A person who exports a file every day is an integration with a single point of failure.
• Not dating the document. A map with no last-updated date loses credibility at the first change.
• Leaving it static. If it is not updated when an integration is added or modified, in six months it becomes fiction again.

Frequently asked questions

What tool is best for the map? The one the team will actually maintain. A well-structured spreadsheet works perfectly for most organisations. A diagramming tool helps communicate the overview to non-technical profiles, but the detail is best kept in tabular format, which is easier to filter and update.

How long does it take to build a complete map? For a medium-sized operation, a few weeks of part-time work, concentrated on interviews and technical validation. The version that is useful for making decisions is usually ready well before the complete version.

Who should lead this work? Someone with a cross-cutting view, not necessarily from IT. What matters is that they have access to every team and the authority to request information. In many organisations it works well for operations to lead it with technical support.

Do integrations that are going to be removed also need to be mapped? Yes, at least at the level of existence and dependencies. An integration planned for removal may be feeding a process nobody associates with it.

How is the map kept up to date? By incorporating its update into the change procedure: no new or modified integration is considered finished without updating the record. Without that rule, the map goes stale within the first quarter.

Checklist to map your integrations

• Is every system taking part in the data exchange identified, including manual processes?
• Is it documented what data travels between each pair of systems and how often?
• Are the transformation rules and exceptions of each flow recorded?
• Does each integration have an identified owner, technical and business?
• Were the known frequent errors of each connection recorded?
• Were the integrations classified by criticality and fragility?
• Was the map validated by the teams that operate each system?
• Is there a rule that requires updating it on every change?

You may also be interested in reading:

• “Legacy middleware migration checklist: risks, stages, testing and owners” • “RFP to choose an iPaaS platform: technical and business requirements you should not leave out” Weavee helps build your company’s integration map as the first step before modernising, with criticality and fragility classified, so the migration is planned on real information and not on assumptions.