Why / when to consider migrating

As the adage goes – “If it ain’t broke don’t fix it”.  If your current system is functioning well and addressing all of your organization’s needs, then you may be better off sticking with what works.

However, if your current system or legacy application is not functioning as well as you need it to, then you many want to consider migrating.  Organizations have many reasons for making changes or migrating their software but, in the end, thedecision comes down to three primary scenarios: 

1. the current configuration is no longer working for you.  You’re dealing with a lot of problems, errors or inefficiencies.
2. You believe you’d be better off migrating.  You may not be dealing with specific problems, but you feel confident that a different solution would offer you and your team improved performance or results.
3. You’re running a legacy version of Access that relies on deprecated or sunset technology that’s limiting your ability to support, maintain, or enhance your system.

Here are a few common reasons when migrating to Azure is worth considering:

Remote access needs  

Many times users need easy remote access to their applications. This can be a problem with Microsoft Access, which is a desktop application.  This means that accessing Access application remotely requires extra effort, such as a VPN with remote desktop applications.

Mobile Responsiveness

 Many users expect to be able to access their applications via a tablet or smart phone.  This is not a capability of MS Access.

Difficulties with maintaining Access on local workstations.  Versions, homogeneity, etc.

Microsoft periodically releases updates or new versions of MS Access. However, some MS access programs rely on specific versions of Access to operate.  This requires network administrators to either avoid upgrading to newer versions of Access, or run the risk of critical applications no longer functioning.  Moreso, maintaining a homogenous version of MS Access across a network of different aged workstations with different operating systems can be problematic.  This has led some organizations to keep a handful of older computers running older operating systems and Office versions to keep the Access programs running. 

Lack of functionality due to Access Limitations

Many of the expected features of modern applications may not be available or may be more complicated in Microsoft Access programs.

Increased demand and significant enhancements needed

While a powerful tool for rapid development, Access does have its limits. If your use case is pushing the limits of Access capabilities, or if you need significant enhancements to the functionality of your application, it may be a good idea consider migrating.

Three options for migrating Access to Azure

Microsoft Access was released by Microsoft in the early 1990s.  Over the years it’s been used to develop all kinds of applications: from basic office inventory, to fairly complicated ERPs. 

On the other hand, Azure is one of the leading cloud service providers offering hundreds of services ranging from virtual servers, to SQL databases, web apps, and data analysis tools, to name a few. 

There are many ways to migrate from Access to Azure.  Here are 3 of the most common general approaches to consider:

Approach 1: Move Access Files	Move MS Access files (front and back end) to a machine hosted on Azure, and remote into that machine.  It is important when taking this approach to move both the front end files and the back end files to the remote system to avoid potential corruption.
Approach 2: Migrate and Link	Migrate the backend to an Azure SQL server and link the SQL tables to the MS Access front end.  This is a viable approach if the functionality of Access is working fine but you are experiencing data corruption, data storage or performance issues.
Approach 3: Migrate and Redevelop	Migrate the backend to an Azure SQL server and rewrite the application to a web application hosted on Azure services.  While a more involved approach, this is best applied when the functionality of Access is no longer meeting the needs of your organization. Things like: lack of remote access, lack of modern functionality or lack of a developer network, can all be factors in deciding on this approach.

Approach #1: Move Access Files

Gotchas

Moving only the Back End Files  

While it may seem that putting the backend (data) file on a cloud server and keeping the front end (forms, queries, reports, etc.) on the local workstations may be a reasonable approach, this should be avoided.  Accessing the data in this way can result in less-than-ideal performance, and could lead to data corruption.

Security concerns without proper resources

Migrating to the cloud often means putting your organization’s private information on a publicly accessible resource.  When done properly, this is safe.  In fact, when done properly this can be a safer alternative than hosting the data on your own network.  However, if you do not have the resources or the expertise to configure your cloud services properly, your data can be vulnerable.

Cost impact

Cloud hosts often charge recurring monthly or annual fees based on the services and usage.  Depending on what your needs are and how you configure your cloud services, these recurring fees can be significant.  A thorough analysis of cloud hosting vs on prem hosting should be completed before migrating.

The main steps to migrate

1. Set up a server on an Azure VPN
2. Set up the folder structure for storing the backend date file and the main copy of the front end file
3. Copy the split Access files into their corresponding folders
4. Link the data tables in the backend file to the front end file
5. Deploy a copy of the front end file to each user.

How long does it take to migrate (in 2025)?

Can be done in a matter of hours or days depending on the number of users.

How much does it cost to migrate (in 2025)?

Monthly hosting costs which usually range from ~$150 – ~$500 per month, plus a few days setting up servers which would usually cost between $1500 – $3500.

Approach #2: Migrate and Link

Gotchas

Not giving each user their own copy of the front-end

A common mistake once the Access application is split into a front end and backend is to provide multiple users links to a single copy of the front-end file.  This can result in:

• slower performance,
• frequent corruption of the front-end file,
• and lingering file locks. 

The recommended approach is to keep a master copy of the frontend, and deploy that into a different folder for each user, so that they are each running their own version of the front end.

The main steps to migrate

1. Set up an Azure SQL Server and Database.
2. Use the Microsoft SQL Migration Assistant for Microsoft Access to migrate the Access Data Tables to the new Azure SQL Database.
3. Review the migrated tables to ensure the database schema and data correctly transferred.
4. Use the Linked Table Manager in Microsoft Access to link to the new SQL tables in Azure.
5. Deploy the updated front end to the users.

How long does it take to migrate (in 2025)?

The amount of effort involved for this approach is driven heavily by:

• the number of data tables,
• the amount of data in the database,
• and the number of users.

For a smaller database with less than 25 tables, less than 10GB of data and a small userbase (1-20 users), this can process can take somewhere between 1 – 2 weeks . 

A larger database can take closer to a month.

How much does it cost to migrate (in 2025)?

Smaller database:

• Migration consulting costs: ~ $7000
• Monthly hosting costs: $350 – $1000

Larger database:

• Migration consulting costs: ~ $15,000
• Monthly hosting costs: $1,000 – $3,000

Approach #3: Migrate and Redevelop

Gotchas

Rewriting or redeveloping software is a significant undertaking and there can be many things to look out for during the process, but a few of the key “Gotchas” are:

Lack of understanding of the legacy application

Not knowing all of the functionality, integrations, or dependencies of the legacy application can result in:

• underestimated time to migrate,
• Underestimated cost to migrate,
• lack of functionality in the new system.

Mission Creep 

 Adding unneeded functionality can quickly blow through budget and timeline. This often happens when features outside the original requirements are added. 

For example:  during a demonstration of the modern application being developed, it’s stakeholders begin to realize additional features the system is now capable of and ask “Can you make it do this…?”  The answer is usually yes, but additional effort is required  to add the new feature.  When these situations arise, it’s important to evaluate if this new “wish” is truly worth prioritizing,or if it should be added to a later phase of development.

The main steps to migrate

1. Identify the feature set required for the new application, including all the necessary functionality of the legacy system, as well as the desired features that can provide a valuable return on investment.
2. Identify the technology stack that the application should be rewritten in.  
3. Identify the migration approach: rewrite and replace vs Strangler Fig Approach (rewrite in place).
4. Redevelop / rewrite the application to meet the requirements.
5. Perform QA testing throughout the development process.
6. UAT (User acceptance testing) prior to the launch of the application.
7. Deploy.
8. Support.

How long does it take to migrate (in 2025)?

The level of effort for this migration approach is heavily driven by factors such as:

• The amount of data in the database,
• the number of users,
• the complexity of application functionality (e.g. advanced engineering or statistical calculations, Complex business logic),
• and regulation compliance (e.g. DFARS, PCI, HIPAA).

Smaller, simpler applications with no regulatory requirements can range from ~3 – 6 months.

Larger, more complicated applications can take ~6 months to 1 year +.

How much does it cost to migrate (in 2025)?

 Smaller database:

• Migration and redevelopment costs: ~$70,000
• Monthly hosting costs: $350 – $1000

Larger database:

• Migration consulting costs: ~$150,000
• Monthly hosting costs: $1,000 – $3,000

How can I get started?

If you’d like us to migrate your Access application to Azure, reach out for a chat.

Access To Azure Case Studies