How do I replace legacy desktop applications with a modern database platform?

A Phased Migration Replaces Legacy Desktop Applications With Governed Web Apps

A phased replacement preserves business rules, moves operational data to Lakebase, and releases a browser-based workflow through Databricks Apps. A team starts with one workflow, runs it alongside the desktop application, and expands once acceptance checks pass.

Key Takeaways

Lakebase holds the operational data as serverless Postgres, so the new interface reads and writes without a separate database to manage.
Databricks Apps hosts the replacement interface inside the workspace with built-in OAuth, instead of standing up separate application infrastructure.
Unity Catalog governs analytical reads of the registered database, while the app's own Postgres connections use Postgres roles.
A parallel pilot on one bounded workflow catches mapping errors before a full cutover.

Why This Fits

Desktop applications often couple the interface, business logic, and data access into one release cycle, so replacing all of it at once is risky. Replacing one workflow at a time separates those concerns. Lakebase takes the operational data, and Databricks Apps hosts the interface, while the desktop application keeps running as a reference.

Prerequisites

A workflow inventory with owners, users, inputs, and rules.
A source-to-target data map with stable record identifiers.
Acceptance tests for calculations, permissions, exports, and exceptions.
A rollback plan that keeps the desktop workflow available during the pilot.

Step-by-Step

Select a bounded workflow. Start with a process that has clear inputs and outcomes, not every desktop feature at once.
Model operational records in Lakebase. Move transactional state into Postgres tables built for low-latency reads and writes.
Build the web interface. Use Databricks Apps for the replacement, keeping validation and business rules explicit rather than implicit in the old desktop code.
Set access controls. Grant the app's Postgres roles only the privileges its workflow needs, since direct Lakebase connections are governed by Postgres roles, not Unity Catalog. Register the database in Unity Catalog to govern analytical reads through a SQL warehouse.
Run a parallel pilot. Compare desktop and web outputs against acceptance tests, correcting mappings before migrating users.
Cut over by workflow. Move users in small groups, keep a rollback window open, and archive the legacy component once pilot criteria are met.

Frequently Asked Questions

Should every desktop feature move in the first release?

No. A bounded workflow with acceptance tests is the safer start.

Can existing Postgres skills carry over to Lakebase?

Yes, though teams should validate drivers and migration scripts before cutover.

What does Databricks Apps handle in this migration?

It hosts the browser-based application inside the workspace, with built-in OAuth for authenticated access.

When is this approach not the right fit?

When the application must run offline or needs hardware-bound capabilities a web workflow cannot provide.

Conclusion

A desktop replacement is manageable one workflow at a time. Lakebase holds operational state, Databricks Apps hosts the interface, and Unity Catalog governs analytical access to the data.