Every on-prem or legacy platform sits inside an ecosystem of integrations that built up over years. Some are documented. Most aren't. When you migrate the platform, those integrations have to be audited, updated, and tested — or they break silently the moment you cut over.
After enough migrations, the same five integration patterns show up as the breakage points every time:
1. Identity and SSO. The integration that authenticates everyone into the platform. When the platform moves, the SSO configuration moves with it — and if the new endpoint isn't registered correctly with your identity provider, nobody can log in on Monday morning. This is the highest-visibility failure possible. Audit it first, test it twice, and have a rollback plan that doesn't require a help desk to execute.
2. The financial integration. Whatever sends data to or from your finance system — payroll feeds, AP integrations, invoice routing. These are usually the oldest integrations in the stack, often built before the current finance team was hired. They're brittle, undocumented, and run on schedules nobody remembers setting. They also have the highest blast radius if they break: missed payroll, late payments, broken reconciliation.
3. The reporting integration. The system that pulls data into your BI tool, executive dashboard, or board reporting deck. Reporting integrations are usually built by analysts, not engineers, which means they live in spreadsheets, scheduled queries, and Power BI connectors that point directly at the platform's old endpoints. After migration, the reports keep running on stale data — sometimes for weeks — before anyone notices the numbers stopped moving.
4. The shadow integration. The one nobody mentioned because nobody owns it. A script written by an engineer who left two years ago. A Zapier zap built by an ops person on her personal account. A vendor portal that scrapes data via a service account whose owner is "IT." These don't show up in the official architecture diagram. They show up in the post-mortem.
5. The downstream consumer. Other internal teams who built their own workflows on top of the platform you're migrating. Marketing's lead-routing automation. The customer success team's onboarding sequence. The recruiter who exports the same report every Tuesday. They're not technically integrations in the architectural sense, but they break the same way: data stops flowing, workflows stop firing, somebody's process quietly stops working.
The fix for all five is the same: a real integration audit before the migration plan is finalized. Not "ask the vendor what integrations they know about" — that gives you the official list. The real audit interviews the people who use the platform daily and asks "what do you do with the data after it leaves the system?" That's where the shadow integrations come out.
A good migration plan has an inventory of every integration, an owner for each one, a test plan for each one, and a rollback procedure for each one. A bad migration plan has a cutover date and optimism.
If you're staring down a cloud migration and the integration list feels too short, it is. Book a scoping call.
