How to Map Systems and Integrations During Discovery
Summary
Integration mapping is where discovery projects either build a foundation for success or quietly set up failure. Most teams treat it as a checkbox exercise, listing systems in a spreadsheet, when it should be a structured assessment of complexity, risk, and architectural constraints.
A List of Systems Isn't a Map
Every replatform involves systems. ERP, OMS, PIM, CRM, marketing automation, payment processors, loyalty platforms, custom middleware. The list grows fast.
Teams don't forget to ask about integrations. They ask. They get answers. They write them down somewhere.
Then the information scatters. Someone captures the ERP details in a meeting note. Another person adds the PIM to a spreadsheet. The architect mentions a custom middleware layer in a call that nobody documents properly.
By the time you're building, nobody has a complete picture. Assumptions get made. Complexity gets underestimated. Timelines slip.
Integration mapping fails for three reasons:
- Incomplete inventory, systems get missed because nobody asked the right stakeholder
- No complexity assessment, a list of system names tells you nothing about effort
- Disconnected from requirements, integrations exist to serve business needs, but the connection isn't tracked
A Framework for Integration Mapping
Mapping systems and integrations requires structured data that connects to the rest of your discovery work.
Build the System Inventory First
Start by building a complete inventory of current systems. Most teams stop too early.
What to capture for each system:
- System name and vendor
- Category (ERP, OMS, PIM, CRM, etc.)
- Owner or responsible team
- Current version
- Hosting model (SaaS, on-premise, cloud-hosted)
- Contract status and renewal dates
Where this breaks: Relying on a single stakeholder to provide the full list. IT knows about infrastructure. Marketing knows about their tools. Operations knows about fulfillment systems. You need input from multiple sources.
Map the Connections Between Systems
Once you have the systems, map the connections.
What to capture for each integration:
- Source system
- Target system
- Data exchanged (orders, inventory, customers, products, etc.)
- Direction (one-way, bidirectional)
- Trigger (real-time, scheduled, event-based)
- Current integration method (API, file transfer, middleware, manual)
Where this breaks: Treating all integrations as equal. A nightly inventory sync via SFTP is not the same as a real-time order submission to an ERP. The complexity difference is significant.
Score Complexity Based on Evidence
Every integration needs a complexity assessment. Without it, you're estimating blind.
Factors that increase complexity:
- Custom or undocumented APIs
- Legacy systems without modern integration options
- Real-time requirements with high transaction volume
- Bidirectional sync with conflict resolution needs
- Multiple data formats or transformation requirements
- Security and compliance constraints (PCI, PII handling)
- Dependencies on third-party middleware
Scoring approach:
Assign each integration a complexity score based on weighted factors. A simple SaaS-to-SaaS connection with a standard connector might be a 1. A custom integration with a legacy on-premise ERP that requires real-time inventory and has no documentation might be an 8.
Where this breaks: Scoring based on assumptions instead of evidence. If you haven't seen the API documentation or talked to someone who maintains the integration, your score is a guess.
Assess Risk and Dependencies
Some integrations are more critical than others. A broken product feed is inconvenient. A broken order integration stops revenue.
What to assess:
- Business criticality (what breaks if this integration fails?)
- Technical risk (how likely is this integration to cause issues?)
- Dependencies (what other integrations rely on this one?)
- Ownership (who maintains this today, and will they be available during the project?)
Where this breaks: Ignoring the human dependencies. If one developer built a custom middleware five years ago and left the company, that's a risk, even if the system technically works.
Connect Integrations to Requirements
Integrations exist to support business requirements. An OMS integration enables order routing. A PIM integration enables product data syndication.
Map each integration back to the business objectives and functional requirements it supports. This creates traceability, you can see why each integration exists and what breaks if it doesn't work.
Where this breaks: Treating integration mapping as a purely technical exercise. When integrations aren't connected to requirements, you lose the ability to prioritize and make trade-offs.
What Good Integration Mapping Produces
A complete integration map gives you:
- A full inventory of systems with ownership and status
- A connection map showing all integration points
- Complexity scores that inform estimation
- Risk assessment that informs planning
- Traceability to business requirements
This isn't a static artifact. It's working data that informs architecture decisions, surfaces risks early, and provides a foundation for realistic project planning.
How DigitalStack Structures Integration Mapping
DigitalStack treats integration mapping as structured data, not documentation.
System inventory with context: Each system captures owner, category, contract status, and hosting model. Systems stay connected to the engagement and link to related requirements and stakeholders.
Integration registry: Connections between systems include what data flows, how it flows, and how complex it is. Each integration links to its source and target systems, change one, and the relationships stay intact.
Complexity scoring: Weighted scoring based on factors you define. Roll up aggregate complexity across an engagement to inform estimates, rather than eyeballing individual integrations.
Requirement traceability: Integrations connect to the objectives and requirements they support. When a stakeholder asks why a particular integration matters, the answer is already documented.
Survey-driven input: Gather system and integration details from multiple stakeholders through structured surveys. Responses flow directly into the registry, no more consolidating spreadsheets.
The result is an integration map that stays current and connects to the rest of your discovery work.
Next Step
See how DigitalStack structures integration mapping as part of connected discovery. Request a walkthrough to see the system module in action.