System Design Case Study

Migrating a Live Communications Platform Without Breaking the System

Reasoning through an Azure Communication Services migration with the Correct Code Framework.

How do you change a communication subsystem inside a live distributed application while preserving its contracts, behavior, availability, observability, and downstream dependencies?

Reason Through the Case Reason Through Your Project Why Garonzick Fits This Work

1. Start With the System Boundary

ACS is probably not the system.

At first glance, migrating away from Azure Communication Services may look like an API replacement project. From a System Design perspective, it is much larger.

ACS is a component inside the system. The migration starts by identifying the boundary around that component and the contract the rest of the application depends on. 

                     +--------------------+
                     |    Client Apps     |
                     | Web / Mobile / API |
                     +---------+----------+
                               |
                               v
                     +--------------------+
                     | Application Layer  |
                     | Business Services  |
                     +---------+----------+
                               |
                    Communication Contract
                               |
                               v
              +--------------------------------+
              | Azure Communication Services   |
              | Calls | SMS | Email | Chat     |
              +--------------+-----------------+
                             |
          +------------------+------------------+
          v                  v                  v
      Webhooks          Event System       External APIs
          |                  |                  |
          +------------------+------------------+
                             v
                    Downstream Systems

2. Discover the Dependency Graph

The first deliverable is the dependency graph.

The job is to trace ACS dependencies through application code, configuration, APIs, webhooks, event handlers, and downstream systems before selecting a replacement technology. 

Order Service
     |
     +---> Notification Service
     |          |
     |          +---> ACS SMS
     |          |
     |          +---> ACS Email
     |
     +---> Customer Service Platform
                |
                +---> ACS Chat
                |
                +---> Status Webhook
                         |
                         +---> Event System
                                  |
                                  +---> Downstream Systems

The Project

Replacing ACS is not “find ACS, replace ACS.”

Before a team can replace an API, migrate a workload, modify an integration, or schedule a production cutover, it has to ask where the existing system depends on ACS and what has to remain true when ACS is removed.

Calling and video

Potential ACS dependency surface.

Call Automation

Potential ACS dependency surface.

Recording

Potential ACS dependency surface.

SMS

Potential ACS dependency surface.

Email

Potential ACS dependency surface.

Chat

Potential ACS dependency surface.

Advanced Messaging

Potential ACS dependency surface.

Job Router

Potential ACS dependency surface.

Discover Dependency GraphMap Target StatePreserve InvariantsValidate ReplacementProve Completion

CCF Case Study

Migrating ACS through the CCF sequence.

01 - Define the Answer Space

A valid answer is not simply “ACS has been removed.” The target architecture, functional equivalence, integrations, production migration, residual dependency, and system stability all have to be proven.

02 - Establish the Problem Space

Identify every surface that can affect the answer: code, SDKs, APIs, configuration, webhooks, identity, eventing, downstream systems, monitoring, and infrastructure.

03 - Build the Decision Space

For every dependency, run the same migration loop: Observe, Understand, Decide, Modify, Validate.

Scanner

How do we find the dependencies?

The first question is not what should replace ACS. The first question is where ACS is actually being used.

Application Code

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

SDK Dependencies

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

REST APIs

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

Configuration

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

Webhooks

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

Identity

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

Eventing

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

Downstream Systems

Inspect this surface for ACS references, contracts, credentials, callbacks, or behavior.

Recorder

Build the Migration Dependency Ledger.

Discovery without memory creates repeated investigation. The ledger turns the migration into measurable work.

DependencyCurrent ACS CapabilityLocationTargetStatus
NotificationServiceSMSC# ServiceReplacement APIDiscovered
CustomerChatACS ChatWeb AppTeams / AlternativeAnalysis
CallRecordingRecording APIWorker ServiceTarget TBDBlocked
StatusWebhookACS EventsAPI EndpointEvent GridPlanned
DiscoveredClassifiedMappedImplementedTestedCut OverVerified

Invariant

What must remain true?

A migration is not successful merely because the new code compiles. The implementation can change. The invariant cannot.

Invariant

Customers must still receive notifications.

Invariant

Authentication must remain valid.

Invariant

Existing webhook workflows must continue processing events.

Invariant

Failed requests must preserve retry behavior.

Invariant

Required records must continue being generated.

Invariant

Monitoring must still detect failures.

Invariant

Production users must not experience unacceptable service degradation.

Operation

Transform current state into target state.

CCF separates what exists, what must remain true, and how the team will change it.

Current State -> Controlled Transition -> Target State -> Verified Invariant

Replace

ACS API -> Microsoft Graph API

Redirect

ACS event -> Azure Event Grid

Refactor

ACS SDK integration -> internal abstraction + replacement provider

Reconfigure

ACS endpoint -> approved destination

Reauthenticate

ACS credential model -> target identity model

Redesign

ACS-specific workflow -> target-platform architecture

Target-State Reasoning

Do not ask “what's the replacement?” Ask what capability the application actually requires.

Microsoft Graph

Evaluate only when the required application capability points here.

Microsoft Teams

Evaluate only when the required application capability points here.

Dynamics 365

Evaluate only when the required application capability points here.

Azure Event Grid

Evaluate only when the required application capability points here.

Logic Apps

Evaluate only when the required application capability points here.

Approved Third-Party Platform

Evaluate only when the required application capability points here.

Test, Dry Run, Cutover

Integration testing becomes proof.

The test is not “does the new API return HTTP 200?” The test is whether the original invariant remains true across the new architecture.

RequestAuthenticationServiceEventWebhookBusiness Outcome

Finalizer

How do we know the case is closed?

Verified

Target integration operating successfully

Verified

Required business workflows verified

Verified

Logs and telemetry healthy

Verified

Production acceptance completed

Verified

ACS requests approaching zero

Verified

ACS spend approaching zero

Verified

Residual usage investigated

Verified

No migration-attributable Sev1/Sev2 regressions during stabilization

Case closed.

Continuous Learning

One migration is a project. Fifty migrations require a framework.

When teams capture scanners, dependency classifications, replacement mappings, invariants, test strategies, rollback strategies, cutover procedures, and failure patterns, they create reusable migration intelligence.

Migration PatternMigration RunbookTraining ExerciseReusable LabOrganizational KnowledgeFaster Future Migration

Correct Code Talent Development

This job description isn't just a hiring requirement. It's a curriculum.

Bring us the architecture. Bring us the job description. Bring us the technical problem. We'll turn it into a reasoning model, implementation roadmap, assessment, and training program.

Reason Through Your Project Build a Training Program Around Your Architecture

Technical Consulting - Talent Assessment - System Design - DevOps - Role-Specific Training