How to discover the integrations nobody documented
Every enterprise migration hits the same wall. Three months into a project scoped at six months, someone discovers an integration that wasn't in any documentation. The finance system sends a nightly file to a subsidiary nobody mentioned. The CRM triggers webhooks to a marketing tool that was set up by someone who left two years ago. The ERP has a custom API endpoint that feeds a reporting dashboard the project team has never seen.
These undocumented integrations don't just delay migrations. They derail them. A single missed integration can invalidate cutover plans, create data inconsistencies, and destroy stakeholder confidence in the project team.
The solution isn't better documentation practices, though those help. It's a systematic discovery process that finds integrations regardless of whether anyone remembers they exist.
Why documentation always falls short
Documentation fails for predictable reasons. Systems evolve faster than documentation gets updated. The person who built the integration moved on before documenting it. The integration was a "temporary fix" that became permanent. The documentation exists but lives in a SharePoint folder nobody can find.
Even well-maintained documentation has gaps. It captures what was intentionally built, not what emerged organically. It describes the integrations someone decided were important enough to document, not the ones they considered too minor to mention.
The integration that breaks your migration is almost always one that fell through the documentation gaps.
The four discovery channels
Comprehensive integration discovery uses four channels. Each catches integrations the others miss. Skipping any channel leaves gaps that will surface at the worst possible time.
Channel 1: Network traffic analysis
Network traffic doesn't lie. If System A sends data to System B, that traffic is visible regardless of whether anyone documented it.
Work with your infrastructure team to analyse traffic patterns for the systems in scope. Look for connections that aren't explained by known integrations. Pay particular attention to traffic that crosses network boundaries, uses non-standard ports, or occurs on schedules that suggest batch processing.
This analysis requires access that many project teams don't have by default. Make it a priority early. The infrastructure team needs lead time, and the traffic patterns need observation over at least a full business cycle to catch weekly and monthly processes.
Channel 2: System log mining
Application logs capture integration activity that network analysis might miss. API calls, file operations, database connections, and scheduled jobs all leave traces in logs.
Focus on logs from the systems being migrated or replaced. Search for external hostnames, IP addresses outside normal ranges, and scheduled tasks that reference other systems. Look for patterns that suggest data movement: files created at consistent times, API calls to external endpoints, database queries that pull data for export.
Log quality varies enormously across systems. Some applications log every external call. Others log almost nothing. Adjust your expectations based on what each system actually captures.
Channel 3: Stakeholder interviews
People know things that logs and traffic don't capture. The finance manager knows about the monthly extract that feeds the board reporting. The operations lead remembers the webhook that triggers warehouse notifications. The IT support team knows about the integration that breaks every time the network team does maintenance.
Structure these interviews around data movement, not system names. Ask "What data leaves this system and where does it go?" rather than "What integrations does this system have?" The first question surfaces flows that stakeholders might not think of as integrations.
Interview broadly. Include business users, not just IT. The marketing coordinator who manually uploads a file every week has identified an integration that needs attention, even if it's not automated yet. The questions you ask at the start of an engagement should include probes for undocumented data flows.
Channel 4: Vendor and contract review
Third-party systems often have integrations that internal teams didn't build and don't fully understand. The SaaS vendor implemented a connection during onboarding. The consulting firm that did the ERP implementation built custom interfaces. The acquired company brought systems with pre-existing integrations.
Review vendor contracts and implementation documentation. Look for references to data feeds, API access, and integration services. Contact vendors directly to ask what connections exist to your systems.
This channel catches integrations that exist entirely outside your organisation's visibility. They're often the most dangerous because they can't be discovered through internal analysis alone.
Building the integration inventory
Discovery produces a list of potential integrations. The next step is building a structured inventory that supports migration planning.
For each discovered integration, capture:
Source and target systems. What sends data and what receives it?
Data entities. What information moves through this integration? Customer records, transactions, reference data?
Frequency and trigger. Does it run on a schedule, respond to events, or operate in real time?
Direction. Is data flowing one way or bidirectionally?
Criticality. What breaks if this integration stops working? The signals that indicate architectural problems often manifest first in integration failures.
Owner. Who understands this integration well enough to answer questions about it?
Some integrations will be well understood. Others will require investigation to complete the inventory. Flag the gaps and allocate time to fill them before migration planning proceeds.
The shadow integration problem
Discovery often reveals shadow integrations that exist outside official IT processes. A business analyst built an automated workflow using desktop tools. A department purchased a SaaS tool and connected it to core systems without IT involvement. A developer created a quick script that's now critical to month-end processing.
Shadow integrations require careful handling. They exist because official processes didn't meet a business need. Simply shutting them down creates problems. But migrating them without review perpetuates technical debt.
Assess each shadow integration against three criteria. Does it serve a legitimate business need? If yes, it should be formally supported. Is it implemented safely? If not, it needs remediation regardless of migration. Can it be migrated as-is or does it need redesign?
The goal isn't to punish shadow IT. It's to bring valuable functionality into the light where it can be properly supported and migrated.
Validating completeness
How do you know when discovery is complete? You don't, definitively. But several indicators suggest you've found most of what exists.
Diminishing returns. New discovery efforts find fewer previously unknown integrations. The fourth round of stakeholder interviews surfaces nothing the third round didn't.
Cross-validation. Integrations discovered through one channel are confirmed by another. The network traffic analysis shows the same connections that stakeholders mentioned.
Coverage confirmation. For each system in scope, you can explain all significant inbound and outbound data flows. No major gaps remain in your understanding of how data moves.
Stakeholder confidence. The people who know these systems best review your inventory and don't identify obvious omissions. They're surprised by how complete it is, not by what's missing.
From discovery to migration planning
A complete integration inventory transforms migration planning. Instead of discovering surprises during cutover, you surface them during planning when there's time to address them.
Each integration needs a migration disposition. Will it be replicated in the new architecture? Replaced by new functionality? Retired because it's no longer needed? Left unchanged because the connected system isn't in scope?
The scoping mistakes that explode migration timelines often trace back to incomplete integration discovery. An integration you don't know about can't be scoped, planned, or tested.
The discovery investment pays off throughout the migration. Testing is more comprehensive because you know what to test. Cutover is smoother because you've planned for all the connections that need to switch. Post-migration support is easier because you're not chasing mystery failures.
Making discovery systematic
Integration discovery should be a defined phase in every migration project, not an informal activity that happens when someone has time.
Allocate dedicated resources. Discovery requires sustained effort from people with access to systems, logs, and stakeholders.
Set a time boundary. Discovery can expand indefinitely. Define when discovery ends and planning begins, even if some gaps remain.
Document the process. What channels did you use? What sources did you consult? This documentation helps assess completeness and supports future projects.
The integrations nobody documented are waiting in every enterprise. A systematic discovery process finds them before they find you.
If you're planning a migration and need to surface undocumented integrations, the PRISM Integration Complexity Assessment provides a structured discovery framework. $750 AUD.