Breaking the Application Rewrite Wall: How Compatibility Architecture Solves the SQL to Open-Source Dilemma

Enterprise database modernization often looks simple from far away: move from commercial licensing to open source, reduce long term cost, and give teams a more flexible platform. The hard part starts when the applications arrive. SQL Server estates can carry years of T SQL logic, SQL Server drivers, stored procedures, connectivity patterns, and operational assumptions that do not move cleanly into PostgreSQL. PostgreSQL usage now reaches 52.50% among large enterprises, showing how strong the pull toward open source has become, but adoption still depends on whether legacy applications can cross the gap without a dangerous rewrite.

Minesh Chande, Sr. WorldWide Specialist Solutions Architect at Amazon Web Services and a BCS Fellow, has spent years sitting with this exact problem, watching enterprises stall out on migrations that looked straightforward on paper. His approach centers on compatibility architecture: finding ways to move SQL Server workloads forward without forcing teams into the rewrites that kill timelines and budgets. In this interview, he makes the case for why that approach is fast becoming the most realistic path through the application rewrite wall.

Minesh, thanks for joining us. In simple terms, what is the application rewrite wall?

The application rewrite wall is the point where a database migration stops being just a database migration. It becomes an application redevelopment effort.

I see this most often when enterprises want to move from SQL Server to a PostgreSQL compatible platform, but the applications around SQL Server are tightly connected to that environment. They may depend on T SQL syntax, TDS protocol connectivity, SQL Server drivers, stored procedures, and years of business logic written for the source system.

When those pieces have no direct equivalent in the target platform, teams face a difficult choice. They can rewrite large parts of the application before moving, attempt a risky full cutover, or delay the modernization program indefinitely. That is the wall. It is not always a lack of interest in open source. Often, it is the fear that the rewrite will create more risk than the migration was supposed to remove.

Why does this problem matter so much for enterprises moving from SQL Server to PostgreSQL compatible platforms?

These systems usually support important business functions. They may sit behind finance, healthcare, retail, reporting, operations, or customer facing services. When a database supports that kind of workload, the migration plan has to protect continuity as much as it improves cost or flexibility.

For many customers, the business case is clear at a high level. They want to reduce dependence on expensive commercial database licensing and move toward open source database platforms. But if the path to PostgreSQL requires replacing drivers, converting large amounts of SQL dialect logic, and rebuilding application behavior, the business case gets harder to defend.

My work on Babelfish for Amazon Aurora PostgreSQL focused on that problem. I led architectural initiatives to help enterprise customers modernize SQL Server workloads while reducing the amount of application refactoring required. The compatibility layer allowed existing SQL Server applications to operate against a PostgreSQL compatible engine while preserving native SQL Server patterns in key areas.

How does Babelfish change the migration path?

Babelfish changes the migration path by creating a compatibility layer between SQL Server applications and Aurora PostgreSQL. Instead of requiring every application to be rewritten immediately, Babelfish supports T SQL compatibility and TDS protocol connectivity, which allows many applications to keep using existing SQL Server drivers during the transition.

That changes the shape of the project. The team can assess compatibility, identify unsupported T SQL constructs, apply mitigation strategies, and move workloads in phases. In my work, this approach helped reduce application refactoring requirements by 80 percent and reduced customer migration costs up to 50 percent by minimizing rewrite and redevelopment effort.

I do not see compatibility as a way to avoid engineering discipline. It is a way to focus the engineering work where it matters. The goal is not to pretend that every SQL Server feature maps perfectly. The goal is to avoid rewriting everything by default.

What does that look like inside a real migration plan?

A practical migration plan starts with assessment. I want teams to understand where T SQL compatibility works, where it does not, which drivers the application uses, how data changes will be moved, and what downtime the business can tolerate.

That is where patterns around Babelfish Compass assessment tooling, AWS DMS integration, change tracking, and linked servers become useful. The objective is to move from a vague modernization ambition to a controlled sequence of steps. First, assess the SQL Server estate. Then validate compatibility. Then plan data movement. Then test the application behavior against the PostgreSQL compatible target.

This is not glamorous work. It is detailed work. But that is exactly why it matters. A migration strategy that looks clean on a slide can still fail if it does not account for SQL dialect behavior, connectivity protocols, and legacy dependencies.

Where does the broader database market fit into this discussion?

The market is moving in the same direction as the engineering problem. Cloud database platform spend represented 64% of DBMS spending in 2024, exceeding on premises database spend. That shift puts pressure on enterprises to modernize database platforms, but it does not erase the application layer that has to come along with them.

I have written on HackerNoon about what I learned running both SQL Server and PostgreSQL at scale, and that experience shapes how I view these migrations. Database modernization cannot be judged only by platform preference. It has to be judged by availability, failover behavior, replication, operational reliability, and whether the business can continue running while the system changes underneath it.

For teams moving critical workloads, the winning question is not simply, “Can PostgreSQL support the target state?” The better question is, “Can the application and the database move together without breaking the business?”

You also worked on change tracking and linked server patterns. Why are those important?

They matter because migration is not only about the first copy of the data. It is also about what happens while the source system is still changing.
In the AWS Database Blog I coauthored on migrating SQL Server databases to Babelfish for Aurora PostgreSQL, I focused on a pattern for using change tracking with a linked server. The issue was specific but important. AWS DMS can support full load migration from SQL Server, but continuous replication may depend on capabilities such as transactional replication or change data capture. Some SQL Server environments do not support those options.

Using change tracking with a linked server gave teams a way to track ongoing changes and replicate them to the Babelfish target. That supports migration paths with minimal downtime because the team is not limited to a one time static move. It can validate, synchronize, and transition more carefully.

What should teams be careful not to misunderstand about compatibility layers?

They should not treat compatibility as a shortcut around assessment. A compatibility layer can reduce risk, but it cannot replace testing, operational planning, or honest evaluation of unsupported features.

I still want teams to evaluate unsupported T SQL constructs. I still want them to test SQL feature behavior. I still want them to understand driver dependencies, downtime windows, and governance requirements. Compatibility helps, but it does not remove the need for disciplined migration planning.

The best way to think about compatibility is as a risk reduction strategy. It preserves what can safely be preserved, identifies what must change, and creates room for incremental modernization instead of forcing everything into one high pressure event.

What does this mean for the future of open source database adoption?

I think the future will depend less on whether enterprises believe in open source and more on whether they have credible migration paths. The global cloud migration services market is projected to reach $70.34 billion by 2030, and much of that demand will come from organizations trying to move legacy systems without disrupting operations.

That is where compatibility architecture becomes more important. Enterprises need migration approaches that reduce licensing pressure, preserve operational continuity, and protect existing application investments while still moving toward scalable managed infrastructure. For open source adoption to keep growing inside large organizations, the migration path has to be realistic for the applications they already run.

What advice would you give teams planning this kind of migration now?

Start with the application. Do not look only at the database engine. Look at the SQL dialect, drivers, stored procedures, data movement needs, downtime tolerance, unsupported constructs, and governance requirements the business cannot lose.

Then build the migration in phases. Use assessment tooling. Test compatibility early. Use replication and change tracking patterns where they fit. Validate the edge cases before production. A strong migration plan is not the one that sounds the boldest. It is the one that lets the enterprise move forward without turning modernization into a rewrite crisis.