Replacing a Dying Access Database or Legacy Tool Without Stopping the Business

What must work next month, and what can wait?

Most replacement projects fail before a platform is chosen, because the urgent problem and the ambitious one get written into the same requirement. The Access database that corrupts every few weeks, the order spreadsheet two people overwrite, the in-house tool whose author has left: those are urgent. A single customer view, automated quoting and a portal for customers are ambitions. Treating them as one project means the urgent part waits for the ambitious part to be designed, and the business keeps losing orders in the meantime.

Spend a day writing two lists before talking to any vendor, including us. The first list is short and operational. The second list is allowed to be long, and nothing on it should delay anything on the first.

• Must work next month: the processes that lose money or orders when the tool fails, who runs them, how often, and what the workaround is today when the file is locked or broken.
• Must be protected now: where the data physically lives, whether there is a tested backup, and whether anyone left in the business can open the design view, the VBA or the macros.
• Can wait: reporting improvements, integrations with other systems, mobile access, customer portals, and any process that works well enough on the current tool.
• Decides the platform later: how many people use it and how lightly, whether you already pay for Microsoft 365, what an auditor or customer will ask to see, and who will own the system in three years.

What are the three honest paths for replacing an Access database or legacy tool?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. For a legacy Access database or spreadsheet estate that recommendation comes down to three paths. None of them is always right, and the column that matters most is the one that says when each is the wrong choice.

When is stabilising the existing Access database the right first move?

More often than vendors admit. Microsoft Access desktop is still part of Microsoft 365 and still supported, so "dying" usually describes the setup rather than the product: one unsplit file on a network share, a 2 GB file size ceiling approaching, VBA nobody left can read, and no restore that has ever been tested. Those are fixable in days, and fixing them turns a crisis into a planned replacement.

Stabilising is a holding position, not a strategy. Set a date by which the replacement decision will be made, and do not add new features to the old tool in the meantime, because every feature added is another thing the migration has to reproduce.

• Take a copy and test the restore before anything else. A backup that has never been restored is a hope rather than a backup.
• Split the database into a back end holding the tables and a front end copy per user, which reduces the chance that one crashed session damages the shared data.
• Where file size, concurrency or remote access is the problem, move the tables to SQL Server or Azure SQL with the free SQL Server Migration Assistant for Access and keep Access as the front end for now. This also leaves the data in a form any later path can read.
• Document what the database actually does: tables, relationships, the queries people run, the reports that leave the building and the macros that change data. That document is the specification for whatever replaces it.
• Stabilising is the wrong move when the process has outgrown the design, when the business now needs people outside the office working in it, or when an auditor needs a record of who changed what, which Access does not keep for you.

When is a Dataverse or Power Apps app the right replacement?

When the business already runs on Microsoft 365, the Power Platform is usually the fastest route off a legacy tool, and part of the entitlement may already be paid for. Access can also export its tables to Dataverse and keep them linked, which lets a team keep familiar Access forms for a transition period while the data already lives in the new platform. Dataverse brings what spreadsheets and Access never had: relationships enforced by the platform, security roles and column level security, and auditing that can be switched on per table and per column.

Be exact about licensing before you commit. A canvas app over a SharePoint list runs on the seeded Power Apps rights in most Microsoft 365 plans, which is why replacing one shared Excel tracker that way is the sensible first project described in Power Platform: the most underused tool in mid-market companies. The moment the app uses Dataverse or a premium connector, every user of it needs premium Power Apps licensing or a Dynamics 365 licence that includes it. If most of your users only need to look something up once a week, price that before the design, not after.

Where the legacy tool is really a CRM, meaning accounts, contacts, opportunities and follow-ups, configuring Dynamics 365 Sales is often faster than building the same thing from scratch in Power Apps. Where it is a capture tool used standing up, such as inspections, quality checks or downtime logs, a canvas app on a tablet is the pattern, and how Power Apps replaces paper forms on the shop floor covers validation at entry and offline capture. Our Power Platform developers build both.

• Who maintains it: a Power Platform app can be maintained by an internal maker for small changes, but the data model, security and release process need someone accountable, whether that is an internal owner or a support arrangement.
• It is the wrong path when the organisation does not use Microsoft 365, when many light users make per-user licensing the largest cost, or when the requirement is to host the data outside the Microsoft cloud.

When is a custom application you own the right replacement?

When the constraint is licensing, hosting or ownership rather than capability. A custom application built on React, Node.js, PostgreSQL or .NET has no per-user licence, runs on your own cloud or servers, and belongs to you from source code to data model. It is the alternative for organisations that Microsoft licensing does not fit, not a verdict that the Microsoft platforms are the wrong tools, and our custom CRM development service is where we build it.

The honest condition is maintenance. An Access database becomes a legacy problem when the one person who understood it leaves, and a custom application written by one contractor without documentation or tests becomes exactly the same problem, only more expensive. Choose this path only if the system will have an owner after go-live: an internal development team, or a support agreement with the team that built it, with the code, the documentation and the deployment pipeline handed over either way.

• Correct when many people need light access, when data must stay on your own infrastructure, when the organisation does not run on Microsoft 365, or when the process is what the business sells and differentiates on.
• Wrong when the replacement is a standard sales or service process that a configured platform already does, when the timeline is weeks rather than months, or when there is no one to own it after launch.

How do licensing, audit and maintenance change the choice?

These three factors decide more replacements than features do, and they are the ones most often left until after a platform has been picked. We do not publish prices, because scope drives every figure, but the shape of each cost is predictable.

Which parts of a spreadsheet process belong in Dataverse, a model-driven app, a canvas app or Excel?

A spreadsheet process is rarely one thing. It is usually a master list, a working screen, a capture form and an analysis sheet living in the same workbook, and each part has a different right home. Splitting it this way is what keeps a replacement small enough to deliver quickly, and it is how the canvas versus model-driven choice is made on our Power Platform service page.

How do you consolidate spreadsheets, Access and the accounting system into one source of truth?

Decide which system owns each kind of record before moving anything. Customers, contacts, opportunities, orders in progress and service history usually belong in the new application. Invoices, ledgers and payments belong in the accounting system, which stays where it is. The single source of truth is not one database holding everything; it is one agreed owner per record type, with an integration that keeps the others reading from it instead of keeping their own copies.

Solzet does not implement finance or ERP systems, including Dynamics 365 Finance, Business Central, NAV or Finance and Operations. Where a legacy accounting package sits alongside the spreadsheets, we integrate the new CRM or application with it rather than proposing to replace it, and we scope that integration as its own piece of work.

• Write an ownership table: each record type, the system that owns it, and the systems that only read it.
• Retire each spreadsheet explicitly once its records have an owner. A spreadsheet that is "no longer used" but still editable will be used.
• Match customers across sources on a stable key, such as the account number from the accounting system, rather than on names typed differently in every file.

How do you migrate off the legacy tool without stopping the business?

By never having a day when the old tool is gone and the new one is not trusted yet. The mechanics are the same whichever path you chose. If the target is Dataverse and there is no budget for tools or a developer, the free step by step load with Power Query, the Data Import Wizard and XrmToolBox is already written up in zero-budget migration from Excel, Access, or legacy systems, and for large tables the Dataverse bulk import strategy covers volume. The sequence around the load is below.

• Extract before you design. Export every table separately, straight from the source, and keep that raw copy read only as the record of what the old system actually said.
• Profile the data before you map it: row counts per table, empty and inconsistent columns, duplicates, values that break the rules the new system will enforce, and child rows whose parent no longer exists. Profiling is what turns an estimate into a plan.
• Keep the old system readable for as long as anyone might need to check history. Make it read only at cutover rather than deleting it, so a disputed record can always be looked up.
• Cut over one process at a time, starting with the one causing the most pain on the urgent list. Each cutover has a date, an owner and a rule that new records for that process are created only in the new system from that date.
• Run in parallel for a defined, short period where the risk justifies it, and compare outputs such as order counts or open jobs between old and new at the end of each day.
• Reconcile before switching the old tool to read only: counts per record type, spot checks on real records chosen by the people who use them, and a signed-off list of what was deliberately not migrated.

Should you do this yourself or bring in help?

A single tracker replaced by a canvas app over SharePoint, or a small spreadsheet loaded into Dataverse with the free tools, is genuinely something a capable internal person can do, and the pages linked above are written so they can. Outside help pays for itself where the decisions are hard to reverse: the data model the next five processes will stand on, the security design, the licensing shape, the integration with the accounting system, and the cutover plan for a process the business cannot afford to lose.

Solzet is a scalable senior consultancy with 8+ years of CRM delivery, and our senior consultants and full-stack developers build on the Power Platform, on Dynamics 365 Customer Engagement and as custom CRM and business applications. Because we deliver all three, the recommendation after a scoping conversation has no reason to lean, and it can be to stabilise what you have and come back later.