Where platform changes reveal gaps
Integration can run reliably today and still need changes when an upstream platform changes. Undocumented dependencies, unclear ownership and missing fallback procedures can make those changes harder to manage.
Exchange Web Services in Exchange Online is a current example. Microsoft's guidance says disablement begins during October 2026, with EWS fully disabled in April 2027. Its migration guidance recommends identifying internal and third-party applications that depend on EWS.
Similar discovery work can be needed when other foundational platforms change. Quarterly and seasonal jobs deserve particular attention because their infrequent schedules can leave gaps in routine monitoring.
What a dependency register captures
A dependency register is a structured record of the business workflows your integrations serve, maintained well enough that a team member who did not build the integration can understand it, own it, and migrate it.
Each row should answer seven questions:
Business workflow served. What does this integration do in business terms? "Syncs customer records to CRM" is useful. "Calls the /sync endpoint" is not.
Source and target. Which system sends and which receives? Include the version each was built and last tested against.
Named owner. One person, not a team, is accountable for this integration's health.
Schedule and frequency. Daily, hourly, quarterly, event triggered.
Last successful run. Date, time, and a record that the business outcome, not just the connection, was verified.
Supported version status. Is the integration running on a version the platform still supports? Has a deprecation notice been issued?
Fallback. If this integration fails, what is the manual or automated fallback? Who executes it?
Quarterly and seasonal integrations
Quarterly and seasonal integrations can be missed by routine monitoring because they run infrequently. Test their expected business outcomes before cutover instead of waiting for the next scheduled production run. A quarterly job that fails may not surface until the next natural run date which, depending on the business, could mean financial reporting, compliance submissions, or operational processes fail at the worst possible moment.
Partner-owned applications
Third-party and partner-owned integrations need their own rows because the migration timeline and effort belong to someone else. If a partner application has not committed to migrating by a specific date, the register surfaces that as an open item before execution.
Testing before cutover
Before approving a platform change, test the business outcome from end to end. A successful request and response alone does not prove that the workflow completed correctly. Verify that the customer record was updated, the order was processed, and the report was generated with accurate figures. These are different levels of confidence, and the difference matters when the integration serves a workflow the business depends on.
A starting point for integration resilience
A dependency register is a practical starting point for reviewing integration resilience. It makes ownership, testing and migration gaps visible before a platform change, and the earlier those gaps are visible, the less expensive they are to close.
Chirpn's API and enterprise integration work spans MuleSoft, FHIR interoperability, medical billing, venue booking APIs, and ETL pipelines. If your organization is approaching a platform change and wants to review your integration estate before a deadline is in view, here is the right starting point.
