Microsoft certification badges banner
Headshot of Michael Korting

Blog

Microsoft 365 • Security • Compliance

Modernizing a 30‑Year‑Old CRM for GCC High: A Practical Case Study

How a near end‑of‑life CRM was integrated into Microsoft 365 GCC High using modern automation, REST APIs, and pragmatic engineering decisions—without rewriting the system.

Background and Context

During Q1 2026, a legacy customer relationship management system—originally developed nearly three decades ago—needed to remain operational during a transition into Microsoft 365 GCC High. The platform was approaching end‑of‑life and slated for eventual replacement, but immediate business and compliance needs required it to be securely integrated into the new environment.

The challenge was not simply connectivity. The CRM relied on legacy patterns for email ingestion, outbound messaging, and file transport—assumptions that no longer held in a government cloud built around modern authentication, REST APIs, and zero‑trust principles.

Design Philosophy: Replace the Integrations, Not the Platform

Rather than attempting to modernize the CRM itself, the strategy focused on replacing the integration surfaces around it. This approach minimized risk, avoided large‑scale refactoring in a fragile codebase, and produced reusable tooling that could outlive the CRM.

Two integration tracks were defined:

  • Inbound email ingestion and file capture
  • Outbound email delivery using modern, compliant transport

Inbound Email Ingestion with Power Automate

The CRM depended on inbound emails as a primary intake mechanism. Existing solutions were not compatible with GCC High authentication constraints, so a new ingestion pipeline was built using Power Automate.

Multiple shared mailboxes were monitored using standardized automation patterns. When new messages arrived, they were exported as structured artifacts:

  • The original email preserved as an .EML file
  • All non‑inline attachments extracted individually
  • A companion .TXT file capturing sender, recipients, subject, and message details

These artifacts were stored in mailbox‑specific locations, creating a consistent and auditable handoff point for the CRM.

Operational Hardening and Reliability Lessons

At scale, reliability mattered more than elegance. Naming collisions, intermittent trigger behavior, and silent failures became the primary risks. To address this, several hardening measures were introduced:

  • Milliseconds added to filenames to prevent collisions
  • Persistent error logging using structured lists
  • Alerting workflows to surface failures immediately
  • Retention controls to prevent uncontrolled data growth

This transformed the automations from “flows that usually work” into a production‑grade ingestion system suitable for regulated workloads.

Outbound Email: Moving Beyond SMTP

The outbound side of the CRM proved even more challenging. Traditional SMTP‑based approaches struggled with modern authentication and government cloud constraints. Rather than forcing legacy plugins to adapt, outbound mail delivery was re‑implemented using REST APIs.

A new Visual FoxPro module was developed that communicated directly with:

  • Microsoft Graph for Exchange Online mail delivery
  • Azure Communication Services Email for high‑volume scenarios

This module handled OAuth token acquisition, token caching, JSON payload construction, attachment encoding, and error handling—entirely within a legacy runtime.

The Role of AI‑Assisted Development

An unexpected accelerant in this effort was the use of modern AI tooling. By combining existing protocol documentation and prior implementation patterns, complete and functional REST‑based modules were produced for a language never designed with OAuth or JSON APIs in mind.

Multiple iterations refined authentication handling, payload correctness, and performance, ultimately delivering a stable mailer that could be adopted widely across the CRM.

Replacing OneDrive Sync with Deterministic File Polling

Early designs relied on file synchronization for transport, which introduced timing and locking issues when used in unattended service contexts. This led to a final refinement: replacing sync with a polling‑based design.

Using Microsoft Graph, the CRM now:

  • Polls designated folders on a fixed interval
  • Downloads files to a local staging directory
  • Processes content deterministically
  • Deletes successfully handled files at the source

This pattern improved reliability and eliminated an entire category of intermittent failures.

Outcomes and Long‑Term Value

By the end of Q1 2026, the CRM remained operational in GCC High with:

  • Modern, secure email ingestion
  • REST‑based outbound messaging aligned with compliance controls
  • Centralized logging, alerting, and retention
  • Integration patterns reusable by future platforms

While the CRM itself will eventually be replaced, the surrounding architecture will not. The project succeeded by treating modernization as a boundary exercise—bringing a legacy system safely forward without forcing it to become something it could never fully be.