Microsoft begins the final phase of SQL Data Sync: what you need to review before 2027

Some services can run in a company for years without practically anyone ever touching them again.

You set up a sync, it solves the problem, and it just stays there. Until one day the provider announces it's going away.

That's what's happening with SQL Data Sync.

Microsoft began the final retirement phase of the service, and as of September 9, 2026, Azure subscriptions that had never used SQL Data Sync can no longer create new deployments.

Customers currently using it can continue operating, but there's a date worth noting right now: September 30, 2027.

That's the day SQL Data Sync will be retired for good.

What was SQL Data Sync?

SQL Data Sync was created to solve a fairly common problem: keeping certain information synchronized across different databases.

You could have, for example, SQL Server on-premises and Azure SQL Database in the cloud.

Data Sync let you select information and sync it between different databases. One especially interesting feature was that it could work bidirectionally.

That made it useful mainly in three scenarios:

• Hybrid synchronization between on-premises infrastructure and Azure.
• Distributed applications that split certain workloads across databases.
• Geographically distributed systems that needed to share information across regions.

Microsoft explains that the service is built on an earlier generation of synchronization technology and recommends migrating to modern solutions that better fit current security and compliance requirements.

What changed now

The retirement really isn't new news.

Microsoft announced back in 2024 that SQL Data Sync would disappear in September 2027. What matters about September 2026 is that we've entered another stage of the process.

New customers are already locked out.

A subscription that has never used SQL Data Sync can no longer start using it.

Existing customers can still keep their deployments running for about another year.

This makes 2026 a much more reasonable time to start a migration than September 2027.

There's no direct replacement

Here's the truly important part of the news, in my view.

Microsoft isn't saying:

Swap SQL Data Sync for this new service.

The official documentation presents several alternatives because it depends entirely on what you're currently doing.

Microsoft maintains an official SQL Data Sync migration guide where it breaks down the alternatives by source, destination, and scenario.

And that table should be reviewed before choosing a technology.

Azure Data Factory doesn't automatically replace Data Sync

This point can lead to mistakes.

You see that Microsoft recommends Azure Data Factory and it seems logical to think that will be the natural migration.

It can be. But it depends.

Data Factory is designed to move, transform, and orchestrate data. It works very well when you need to copy information periodically or perform incremental loads.

Bidirectional synchronization has a different level of complexity.

If two systems can modify the same record, you need to decide what happens when both sides change information before syncing.

Who wins?

Which update is the correct one?

What do you do with a deleted record?

That behavior is part of the architecture and doesn't disappear just because we change products.

That's why a Data Sync migration can end up being a small reengineering project.

The first thing I'd review

Before choosing any alternative, I'd take inventory.

1. Which Sync Groups are still active

It seems obvious, but in systems that have been around for years, there can be synchronizations that nobody remembers.

You need to identify which ones are still necessary.

2. Which databases are involved

I'd clearly document the source, destination, and location.

Especially if there's on-premises SQL Server infrastructure connected to Azure SQL Database.

3. Synchronization direction

This detail completely changes the available alternatives.

Copying information from a central server to Azure is not the same as allowing modifications from both sides.

4. Frequency

A synchronization that runs every night has very different needs from one running every few minutes.

5. Volume

Moving a few thousand records is not the same as keeping tables with millions of rows in sync.

6. Conflicts

This is probably the point I would review most closely in bidirectional systems.

You need to understand what currently happens when two databases modify the same information.

If that rule exists inside Data Sync and nobody documented it, migrating can silently change the system's behavior.

I wouldn't wait until 2027

Microsoft has given plenty of time.

The original announcement came roughly three years before the definitive retirement precisely to allow organizations to plan the transition.

But a year goes by very quickly when we're talking about enterprise systems.

You have to discover dependencies, select technology, configure infrastructure, migrate, run load tests, validate data, verify failure recovery, and finally switch production.

And that's assuming everything is documented.

In legacy systems, that last part is usually optimistic.

My takeaways

I've worked enough years with SQL Server and enterprise systems to distrust any automated process that "has been running without issues for years."

It usually means nobody has ever had to review it.

Until they do.

The retirement of SQL Data Sync seems to me a good example of technical debt that isn't necessarily in the code.

There's also debt in infrastructure, managed services, versions, integrations, and architectural decisions that seemed permanent when they were implemented.

Microsoft is giving plenty of notice.

I would take advantage of that time.

Conclusion

SQL Data Sync will keep working for existing customers until September 30, 2027. Microsoft didn't shut it down today.

But the final stage has already begun.

New subscriptions that never used the service can no longer deploy it, and Microsoft is pushing current customers toward more modern technologies.

The important work now isn't simply choosing between Azure Data Factory, Always On, or replication.

It's understanding why each current sync exists.

Once you know what problem it was solving, you can choose its replacement correctly.

Waiting until September 2027 turns a planned migration into a perfectly avoidable emergency.

Microsoft's official documentation on SQL Data Sync already clearly shows the retirement date. If you have this service in any environment, that would be my starting point.