Dynamics 365 Data Sovereignty: How to Migrate Without Your Data Ever Leaving the Network

In the world of enterprise data migration, there is a massive contradiction that nobody talks about.

On one hand, your CISO (Chief Information Security Officer) has spent millions locking down your on-premise network. You have firewalls, VPNs, and strict Data Sovereignty policies that say: "Production data must never leave our control."

On the other hand, you have a deadline to move to Dynamics 365 Online before the 2026 End-of-Support Cliff.

Here is the problem: Most migration tools require you to break your own rules.

To use a standard SaaS migration platform, you usually have to whitelist their IP address, open a port, and let them suck your data onto their servers to process it.

For a bank, a healthcare provider, or a government agency, that isn't just a "risk." It's a compliance violation.

This post isn't about why you should move. It's about Architecture. I'm going to explain the specific security flaws in the "Standard SaaS" migration model and detail an architecture that satisfies a paranoid security team: The Binary-on-Client method — running a standalone executable inside your network (whether that's an on-premise server or a VPC you control in Azure/AWS).

The "Middle-Man" Risk of SaaS Tools

To understand the solution, we have to look at the flaw in the current industry standard.

When you use a popular "Drag-and-Drop" tool, you are essentially agreeing to a "Man-in-the-Middle" attack on your own data.

The Typical Data Flow:

1. Source: Your Secure SQL Server.
2. The Middleman: The Vendor's Cloud Server (AWS/Azure).
3. Destination: Your Dynamics 365 Tenant.

The Port 1433 Nightmare

To make Step 1 happen, the vendor will ask you to open Port 1433 (SQL) or install a "Gateway Agent" that tunnels out to them.

From a security perspective, you are punching a hole in your firewall to let a third party read your most sensitive DB rows.

Once the data leaves your network to go to their server for processing:

• Data Residency: You lose control of where the data is physically processed (is it in the US? EU? APAC?).
• Data Persistence: Do they cache your data? Do they keep logs? If they get hacked, do you get breached?

If you are migrating Exchange Email data, this risk triples, because email archives contain PII, passwords, and sensitive internal comms.

How This Compares to Other Approaches

The Binary-on-Client model is not the only way to keep data inside your perimeter. It's worth knowing the alternatives and their trade-offs.

Dimension	SaaS Migration Tool	Azure Data Factory (Self-Hosted IR)	Binary-on-Client (Our Approach)
Data Custody	Vendor holds data during processing	Data stays in your network (IR runs locally)	Data stays in your network (binary runs locally)
Inbound Ports Required	Yes — Port 1433 or vendor gateway	No — outbound-only to Azure	No — outbound-only (HTTPS 443)
Transformation Flexibility	Limited to vendor's UI/mapping	Data Flows / custom activities	Fully custom, compiled into the binary
D365-Specific Logic	Varies by vendor	You build and maintain all D365 pipeline logic	Pre-built for Dynamics 365 entity mapping
Failure Recovery	Vendor-dependent	Pipeline retry/checkpoint built-in	Checkpoint-based; resumes from last committed batch
Auditability	Vendor logs (you may not control retention)	Azure Monitor / Log Analytics	Local logs on your server; you own everything

Azure Data Factory with a self-hosted Integration Runtime is Microsoft's own answer to this problem. It keeps data inside your network and pushes outbound to Azure services. It's a legitimate option — especially if your team already has ADF expertise. The trade-off: you're building and maintaining all the Dynamics 365 entity mapping, relationship threading, and error-handling logic yourself. For complex migrations with dozens of custom entities, that's a significant engineering investment.

SSIS packages running on-premise are another common path, particularly for teams already familiar with SQL Server Integration Services. The limitation is similar: SSIS gives you a general-purpose ETL engine, but Dynamics 365–specific logic (option sets, lookups, polymorphic relationships) has to be hand-coded.

The Binary-on-Client approach packages all of that D365-specific logic into the executable itself, so the client's involvement is running it — not building the pipeline.

The Alternative: Binary-on-Client Architecture

For regulated industries, "Trusting the Vendor" is not a valid security strategy. Isolation is the only valid strategy.

The core philosophy is simple: Bring the code to the data, do not bring the data to the code.

Here is how the architecture functions:

1. Compile, Don't Connect

Instead of connecting a SaaS tool to your database, the migration logic is written and compiled into a standalone Binary Executable (.exe).

• This binary contains all the mapping logic (e.g., "Map Table A to Entity B").
• It contains the transformation rules.
• It contains the error handling.
• Crucially: It contains Zero Data. It is just an empty engine.

2. Execution Inside Your Perimeter

You take this binary and place it on a server you control — either an on-premise machine or a VM inside your own cloud VPC.

You (the client) run the executable.

The New Data Flow:

• Source: Your On-Prem SQL (Internal IP 192.168.x.x).
• Processor: The Binary (Running on Your Server at 192.168.x.y).
• Destination: Dynamics 365 Dataverse Web API (Encrypted HTTPS, Port 443).

The binary authenticates to Dynamics 365 using OAuth 2.0 with a Service Principal registered in the client's own Entra ID (Azure AD) tenant. The client controls the app registration, the client secret or certificate, and the API permissions granted. No ClonePartner credentials are embedded in the binary.

3. Outbound-Only Traffic

Because the binary runs inside your network, it talks directly to your local SQL server over your private LAN.

It then pushes data out to Dynamics 365 via standard HTTPS (Port 443).

You do not need to open Inbound Ports.

You do not need to whitelist a vendor's IP.

The data goes from You to Microsoft. It never touches a third party.

4. Failure Recovery: Checkpoints and Resume

Migrations fail mid-run. Networks drop, API rate limits hit, servers restart. The architecture has to handle this.

The binary uses a checkpoint system: after each batch is committed to Dynamics 365, it logs the last successfully processed record ID locally. If the process is interrupted, restarting it picks up from the last checkpoint — not from the beginning.

This means partial migrations are always detectable (compare checkpoint log to source record count) and resumable without duplicating data.

What This Architecture Eliminates — and What It Doesn't

No architecture eliminates all risk. Calling any approach "breach-proof" would be dishonest. Here's what this model actually changes in the threat landscape:

Attack vectors eliminated:

• Vendor-side data breach: There is no vendor-side data store to breach. The data never leaves the client's network except to go directly to Microsoft's Dynamics 365 endpoints.
• Data residency violations: Processing happens on the client's own infrastructure, in the client's own jurisdiction.
• Inbound firewall exposure: No inbound ports are opened. No third-party IPs are whitelisted.

Attack vectors that remain (and are the client's responsibility):

• Client-side insider threat: Anyone with access to the server running the binary can observe the data in transit. Standard access controls apply.
• Compromised binary: If the binary itself were tampered with before execution, it could exfiltrate data. This is why code review and binary integrity verification matter (see below).
• Credential theft: If the Service Principal credentials are compromised, an attacker could authenticate to D365 independently. Clients should use certificate-based auth and restrict the Service Principal's permissions to the minimum required scope.

This is a more honest framing than "impossible to breach." The architecture shifts the trust boundary: instead of trusting a vendor's cloud infrastructure, you're trusting your own network and your own access controls — which is where your security team's expertise already lives.

Handling "Data Sovereignty" for Files & Blobs

Database rows are one thing. But what about the terabytes of file attachments (PDFs, Contracts, Scans)?

As I mentioned in the Hidden Costs of Migration, storing these in Dynamics 365 is expensive. But moving them securely is also hard.

If you upload files to a third-party migration tool, you are creating massive copies of your sensitive documents on their servers.

The Binary-on-Client Advantage:

With this method, the binary streams the file directly from your local file share to your own Azure Blob Storage.

• It uses a streaming method (reading chunks of data into RAM and flushing them to Azure Blob via HTTPS).
• It never writes the file to disk on the processing server.
• It never "saves" a copy.

The target Azure Blob Storage region is chosen by the client — so data residency for file attachments is fully under your control.

This is critical for SharePoint Migrations, where document security is often more important than the data itself.

Regulatory Mapping: Where This Architecture Fits

Security architecture is only useful if it maps to the compliance frameworks your auditors actually care about. Here's how the Binary-on-Client model maps to common regulatory requirements:

• GDPR Article 28 (Data Processor Obligations): Under GDPR, any entity that processes personal data on your behalf is a "data processor" and triggers Article 28 obligations — including a Data Processing Agreement, audit rights, and sub-processor disclosure. With the Binary-on-Client model, ClonePartner never processes your data. The binary runs on your infrastructure, under your control. This can simplify your Article 28 compliance posture because there is no third-party data processor in the migration chain.

• HIPAA (Business Associate Agreements): In a traditional SaaS migration, the vendor touches PHI and must sign a BAA. With this architecture, the vendor never accesses or stores PHI — the binary runs inside your HIPAA-compliant environment. Whether a BAA is still required depends on the specifics of engagement (e.g., if ClonePartner engineers access the environment for troubleshooting), but the architecture itself minimizes the scope.

• Data Residency / Sovereignty Requirements: For organizations bound by national data residency laws (e.g., German Bundesdatenschutzgesetz, Australian Privacy Act), the architecture ensures processing happens on infrastructure you choose, in a jurisdiction you control. No data transits through a vendor's servers in an unknown region.

This isn't an exhaustive compliance mapping — your legal and compliance teams should validate against your specific regulatory obligations. But the architectural decisions described above are specifically designed to reduce the compliance surface area of the migration itself.

Why "Hybrid" is Not a Security Solution

I often hear CISOs ask:

"Can't we just stay On-Premise? Isn't that safer?"

In 2015? Maybe.

In 2026? No.

Keeping data on an on-premise server after the 2026 Support Cutoff is the security equivalent of storing your gold in a vault that has no lock.

• No Security Patches: When a new "SQL Injection" vulnerability is discovered in 2027, Microsoft will patch the Cloud instantly. They will not patch your legacy SQL 2016 server.
• Identity Drift: On-Premise relies on old Active Directory security (NTLM/Kerberos). The world has moved to Zero Trust (Entra ID).

The risk isn't being in the cloud. The risk is the transition.

Once you are in Dynamics 365, you are protected by Microsoft's billion-dollar security budget. You just need to survive the move.

How ClonePartner Delivers This

Because we are an engineer-led service, we can accommodate the requirements of a strict security team.

1. Code Transparency: For high-compliance projects, we offer a source code review. We show your security engineers the source code of the migration script before we compile the binary. They can verify that no data is being logged or exfiltrated.
2. Binary Integrity: The compiled binary is delivered with a cryptographic hash (SHA-256). Your team can verify the hash before execution to confirm the binary matches the reviewed source code and hasn't been tampered with in transit.
3. No Admin Rights Needed: Our binary doesn't need Domain Admin rights. It just needs "Read" access to the specific SQL tables being migrated, plus the Service Principal credentials for D365 (which your team controls).
4. The "Kill Switch": Since the process runs on your server, you have total control. If you see a spike in network traffic you don't like, you kill the process. Restart it later and it resumes from the last checkpoint.