Dynamics 365 & SharePoint Migration Costs: The 4 Hidden Fees

Most online "Cloud Migration Cost Calculators" are designed to do one thing: sell you licenses. They calculate the happy path — a world where your data is perfectly clean, your storage needs are minimal, and your legacy SQL server doesn't have 15 years of custom columns nobody documented.

But with the Microsoft 2026 End-of-Support Deadline approaching, teams are discovering that the actual cost of moving from Dynamics GP, SL, or On-Premise CRM to the Cloud isn't just the subscription fee. It's the hidden line items that standard vendors don't put on the brochure: storage tiers, API limits, downtime losses, and the massive, silent cost of dirty data.

This article breaks down those real cost drivers, explains where the money actually goes, and describes the engineering approaches that prevent budget shock three months into the project.

1. The "Dataverse Tax": Why Your Database is Suddenly Worth Gold

The biggest financial surprise in most Dynamics 365 migrations is storage.

On-premise, storage is effectively free. You bought a hard drive for your SQL Server, threw 50GB of PDF contracts, email attachments, high-res product images, and massive CAD files into it, and nobody cared.

But when you move to Microsoft Dataverse, you are moving into a high-rent district.

How Dataverse Storage Works

Dataverse storage is billed across three separate categories, each with different pricing:

• Database storage — relational data (contacts, accounts, opportunities, custom entities). This is the most expensive tier.
• File storage — attachments, documents, images stored via the file column type.
• Log storage — audit logs, activity tracking.

Dynamics 365 typically gives you a base storage allowance (e.g., 10GB for database, 20GB for files). If you simply "Lift and Shift" your unoptimized on-premise database to the cloud, you will hit that limit on Day 1.

Dataverse database storage can cost upwards of $40 per GB per month (refer to Microsoft's current Dataverse capacity pricing for exact rates by license type, as these change). File and log storage are cheaper per GB, but most migration tools dump everything into database storage indiscriminately.

If you have a 200GB database full of unoptimized data and it all lands in the database tier, that is an extra $8,000 per month — $96,000 a year just to host files you probably don't even look at.

The Fix: Data Separation During Migration

The solution is to separate your data streams during the migration, not after:

1. Relational data (high value): Contacts, Accounts, Opportunities, and Revenue data go to Dataverse database storage. This is the data you need for reports, dashboards, and Copilot.
2. Binary/file data (low value, heavy): PDFs, images, email attachments, and old contract scans go to Azure Blob Storage — which costs pennies per GB compared to Dataverse database storage.
3. The link: A script inserts a URL into each Dynamics 365 record that points to the corresponding Azure file.

The user experience is identical — your sales team clicks the link and the file opens. But your monthly cloud bill drops dramatically.

A standard drag-and-drop migration tool won't do this. It doesn't have the logic to route data to different storage tiers. It just moves everything from Point A to Point B at the most expensive rate.

2. The "Labor Tax" of Cheap Tools: The Validation Paradox

This is the most counter-intuitive part of migration economics: the cheaper the migration tool, the more you pay in labor.

A typical scenario: you buy a low-code migration tool for $500/month. You assign two internal engineers to run it. They're smart, but they aren't migration specialists. They spend weeks struggling with:

• Orphan record errors — records that reference parent entities that haven't been migrated yet (e.g., a Contact pointing to an Account ID that doesn't exist in the target system).
• Date and locale format mismatches — source dates in DD/MM/YYYY landing in a system expecting MM/DD/YYYY.
• Tool crashes at scale — the tool handles 5,000 records fine but fails silently at 50,000.

When the data finally lands, there's a 10% error rate. Someone has to manually open spreadsheets, cross-reference IDs, and validate thousands of rows.

The tool cost $500. The real cost is two engineers off your product roadmap for six weeks, plus the opportunity cost of everything they didn't build.

The alternative is a fixed-fee, engineer-led migration where the vendor writes the scripts, maps the data, runs validation, and owns the outcome. When you factor in the fully-loaded cost of your team's time, the "expensive" option is often cheaper than the "cheap" tool.

3. The "API Throttling" Speed Trap: The Cost of Downtime

Time is money. In migration, time equals downtime.

Microsoft enforces Service Protection API Limits (throttling) on Dataverse. These limits are designed to prevent any single client from monopolizing shared resources. The specific limits are published in Microsoft's Service Protection API Limits documentation and include constraints such as:

• Number of requests per user per 5-minute sliding window
• Execution time per user per 5-minute window
• Number of concurrent requests

If your migration tool isn't optimized for these limits, it hits the throttle and gets a 429 Too Many Requests response. Your migration slows to a crawl.

• Estimated time: 2 days.
• Actual time: 14 days.

The Business Cost of Extended Downtime

The cost of your sales team being unable to access their CRM for 14 days instead of a weekend is real — lost deals, stalled pipelines, manual workarounds on spreadsheets. The exact dollar figure depends on your team size, deal velocity, and pipeline value, but it is never zero and it is never small.

This is a hidden cost that no license calculator shows you.

The Engineering Approach to Speed

The solution is treating migration speed as a performance engineering problem:

• Multithreading: Opening multiple parallel connections to maximize throughput without tripping per-user limits (often by distributing load across multiple application users).
• Optimized batch sizes: Grouping records to maximize payload per API call.
• Throttle-aware retry logic: Detecting 429 responses, backing off for the required interval, and resuming automatically — staying at the exact edge of the limit without triggering sustained blocks.

The goal is a weekend cutover: team leaves on Friday using the on-prem system, comes back Monday morning to a fully populated cloud environment. Downtime cost: near zero.

4. The "Remediation" Cost: Cleaning Dirty Data

Your data is dirty. Everyone thinks their data is clean. It isn't.

• Emails formatted as john@gmail (missing the .com).
• Phone numbers with text in them (555-0199 ext 4).
• Duplicate accounts named "Acme Corp" and "Acme Corporation."

If you migrate this to the cloud, two things happen:

1. You pay to store it (see Dataverse Tax above).
2. Your new system's intelligence breaks. AI features like Microsoft Copilot produce garbage outputs when the underlying data is a mess.

The Hourly Billing Trap

Many implementation partners quote a low price for migration, then bill $200/hour for "Data Cleansing Services." They spend weeks manually fixing spreadsheets. The cleansing phase becomes the most expensive part of the project.

In-Flight Cleaning: Cleansing as Code

The better approach is to treat cleansing as code. You define the rules:

• "If a contact hasn't been active since 2015, don't migrate it."
• "If the phone number contains text, strip the text."
• "If two accounts match on name + address, merge them."

Those rules go directly into the migration scripts. Data is cleaned while it moves — deduplication, format normalization, and archival filtering happen in the pipeline, not as a separate billable phase.

5. SharePoint Migration: The Parallel Cost Nobody Budgets For

Most Dynamics 365 migrations involve SharePoint, but teams budget for them separately — or not at all. When your on-prem Dynamics environment stores documents via SharePoint Server integration, moving to Dynamics 365 Online means your SharePoint environment needs to move too.

The hidden cost drivers in SharePoint migration include:

• Site and library count: Each site collection must be mapped and migrated. Organizations with hundreds of team sites face a planning burden that dwarfs the Dynamics data migration itself.
• Permissions complexity: On-prem SharePoint permissions rarely map cleanly to SharePoint Online / Azure AD groups. Rebuilding permission structures is labor-intensive and error-prone.
• Version history: Migrating full version history for documents dramatically increases data volume and migration time. Deciding how many versions to bring (all, last 5, latest only) is a cost-vs-compliance tradeoff.
• Custom workflows and InfoPath forms: If your SharePoint environment uses legacy workflows or InfoPath forms, these do not migrate to SharePoint Online. They must be rebuilt in Power Automate or replaced entirely. (See our InfoPath & SharePoint Workflows Ending 2026 guide.)
• SPMT limitations: Microsoft's free SharePoint Migration Tool (SPMT) works for basic moves but has documented limits on file path length, metadata fidelity, and throughput. Complex environments often require additional tooling.

If you are budgeting for Dynamics 365 migration and your environment includes SharePoint integration, budget for SharePoint separately and explicitly. The two migrations are coupled but the costs are independent.

6. The Security Cost: Keeping Data In Your Environment

Many SaaS migration tools require you to give them access to your database. Your data flows through their servers.

If you are in healthcare or finance, that is a compliance concern. The legal costs of signing a DPA (Data Processing Agreement) with a third-party vendor can take months and cost thousands in legal fees.

The alternative architectural pattern is running the migration binary inside your own environment:

1. The migration code is compiled into a standalone executable.
2. You run it on your own server (or your own cloud VPC — Virtual Private Cloud).
3. Data flows directly from your source to your destination. It never traverses a third-party network.

This is sometimes called a "bring your own compute" model. The migration agent runs inside your firewall or your cloud tenant. The vendor provides the code; you provide the runtime environment.

• Compliance cost: Near zero — no third-party data processing to negotiate.
• Security risk: Minimized — data stays within your network boundary.
• Legal overhead: Dramatically reduced.

Summary: The Real Budget Checklist for 2026

To get a real budget number, stop looking at the license cost calculator. Instead, work through these questions: