Microsoft Access in the Enterprise: Migration, Support, and Modernization

• Errors suddenly occur after Office or Windows updates
• Performance drops as soon as more data or more users are added
• Multiple versions are in circulation and no one knows which one is the current one
• Critical logic is embedded in VBA macros that hardly anyone understands anymore
• Knowledge is tied to a single person or an external partner who may leave
• Interfaces to ERP or CRM are unstable or missing entirely
• There is uncertainty regarding backups and recovery

Does this sound familiar? Then you need someone to make your Access solution stable and predictable again. That’s exactly what we’ve been doing for years, including for the Swiss Builders’ Association, Thurbo, Sulzer, BWS Limmattal, and the Diocese of St. Gallen. Depending on the situation, this means support, takeover, or modernization.

• 2 GB database limit as a hard technical limit
• Multi-user operation becomes critical with approximately 25 or more concurrent users
• Microsoft support for Access in current Office versions is not guaranteed beyond October 2029

Not every company needs a replacement right away. In practice, there are three sensible approaches, depending on the situation.

1. Access Support and Maintenance

Many people search for “MS Access Support” and mean different things by it. For us ,support always encompasses two levels: quick help when there’s an urgent issue, and thorough stabilization to prevent it from happening again.

Typical triggers

• Errors occur after updates, but the solution is fundamentally sound.
• Performance and data structure become a noticeable bottleneck.
• Further development is happening, but only with risk and gut instinct.

Important steps

• Analyze and permanently resolve issues
• Improve performance and data structure
• Ensure operational reliability: Backups, recovery, clear responsibilities
• Implement small enhancements cleanly without introducing new risks
• Reduce technical debt so that changes can be planned again

2. Access Takeover and Stabilization

Ideal when expertise is lacking or the solution needs to be handed over to new management.

Typical triggers

• Knowledge is tied to a single person or an external partner who has left or is no longer available.
• No one knows for sure how the solution really works, and making changes is risky.
• Environments have been replaced, and suddenly the application is no longer running reliably.

Our Services

• Restore the environment to a working state and clarify dependencies
• Make logic, data model, and critical points traceable
• Identify risk hotspots: macros, queries, forms, interfaces
• Build documentation so knowledge isn’t just in people’s heads
• Create a backlog: what needs to be stabilized immediately and what can be improved later

3. Modernization or Replacement

Appropriate when requirements grow or Access reaches its limits.

Typical triggers

• More teams are working in parallel, and you need centralized traceability.
• Security, role, and audit requirements are increasing significantly.
• Integrations are becoming more important, and the interfaces are unstable today.

Possible modernization paths

• Gradual modernization without rebuilding everything from scratch
• Migrate data to a robust database, offload Access as the front end
• New user interface or web application while processes continue to run
• Replacement when complexity, security, or scalability require it

The goal is to make your solution manageable again: technically functional, conceptually understandable, and operationally secure.

Phase 1: Understanding and making it operational

• Ensuring the application and environment can start up stably
• Identify dependencies: files, links, permissions, interfaces
• Initial risk list: what is acute, what will become dangerous in the medium term

Phase 2: Stabilize and make operational

• Reducing sources of error and improving performance
• Define a backup and restore strategy, including responsibilities
• Create basic documentation: structure, main logic, critical points

Phase 3: Roadmap for further development or modernization

• Prioritized backlog: what delivers quick stability, what delivers lasting impact
• Comparison of options: support, modernization, replacement
• Rough cost estimate and next steps so you can plan effectively

Concrete results from a typical takeover

• A working development and runtime environment, including an overview of dependencies
• Overview of the data model, core logic, critical macros, queries, and forms
• “Risk list” with quick wins and immediate actions
• Backup and recovery, including responsibilities and testing
• Prioritized backlog plus roadmap options for the next steps

Ask any AI how to modernize your Access solution, and you’ll almost always get the same answer: Move the data out of Access and into an MS SQL Server, while keeping Access as the front end. From a 1-tier to a 2-tier architecture. That sounds neat, but in many cases it’s still the wrong decision.

The reason lies not in the technology, but in the data structure of your solution. Migrating to SQL only benefits you if your data model can be divided into clearly defined business domains. If data and forms have been tightly intertwined for years, you’re just shifting the problem. You’re making a costly investment, and the root cause remains. That’s why we first examine a single, crucial question: Can your Access solution even be cleanly separated?

A purely technical analysis shows you how your Access solution is built. It does not show you what it actually does from a business perspective. This is the most common mistake made when deciding to modernize: people evaluate the technology and overlook which logic is critical to business operations.

That is why we always supplement the technical assessment with a usage analysis from a process perspective, including a clickable prototype. Only then does it become clear which functions are business-critical and what needs to be transferred to a new solution. In several projects, this has led us to a recommendation that is completely different from what a technical review or AI could ever have provided.

1. Keep using Access.

Is it running smoothly and performing well? Then make a conscious decision to wait it out. That’s often the most cost-effective choice. Just keep an eye on the timeline: the end of support and the day the only person with the know-how leaves.

2. Migrate the backend to SQL Server.

The classic approach: You put the data into a relational database, while Access remains the front end. But this only works if your data model can be neatly separated into business units. We’ve seen projects where this very step ended up yielding almost nothing: money wasted on a technology that was phased out anyway.

3. Replace the Access front end.

You keep the data and replace the interface with a web application. The same condition applies as in Option 2. Often the smartest intermediate step toward a new solution, because you spread out the risk and effort.

4. Replace with off-the-shelf software.

If your processes are close to standard, a commercial product can often fully replace Access. We only build the parts ourselves that truly set you apart from the competition. The rest is covered by standard software, which is cheaper and easier to maintain.

5. Build from scratch.

This is considered risky, and that’s true if you start without a plan. If your solution can’t be phased out gradually, building a new system in parallel is still the cleanest approach. You rebuild using a fresh domain model, migrate the data in a single cutover, and keep the old solution running as a read-only reference until the new system is up and running.