Three different jobs all get called “migration”, and the right one depends on what’s actually hurting. Moving off an old version of Access onto a current one. Keeping Access but putting the data somewhere that copes with twelve people at once. Or getting at the system from outside the office, which is what most people mean when they say cloud.
We’ve specialised in Access since 1999. Ring ☎ and we’ll tell you which of the three you need, usually inside one conversation, before anybody quotes you for a rebuild.
Which one do you actually need?
Version upgrades and conversions
Access 97, 2003 and 2007 databases still run plenty of UK businesses. They keep going until something forces it: a new PC with 64-bit Office, a Windows update, or the last machine that could open the file finally dies.
What usually needs doing:
- .mdb to .accdb conversion, or a considered decision to stay where you are
- 32-bit to 64-bit Office, which is where most upgrades actually break. Declare statements, DAO and ADO references, ActiveX controls, and anything relying on a 32-bit ODBC driver
- VBA that compiled fine in 2007 and won’t now Access VBA development
- Missing references and libraries Microsoft has since dropped
- Testing every form, report and export before anyone relies on it
Access web apps and Access services in SharePoint were retired by Microsoft years ago. If anyone has offered you that as the upgrade path, it doesn’t exist.
Upsizing: keep Access, move the data to SQL Server
[IMG-2] — Left-aligned, half column. Real evidence of a migration done properly: Linked Table Manager showing tables linked to SQL Server, an SSMA conversion report, or a before/after record count reconciliation. Redacted, numbers visible.
Alt: Microsoft Access tables upsized and linked to SQL Server
The symptoms are recognisable. It crawls when more than a few people are in. The back end is creeping towards the 2GB ceiling. You get corruption after a network drop. Someone’s been told not to use it during month end.
The fix is usually not a new system. Split the front end and back end properly, move the tables to SQL Server or Azure SQL, relink, and rework the queries that were doing their work on the wrong side of the network. Users open the same forms they opened yesterday.
- Front end / back end split if it hasn’t been done, one copy of the front end per PC
- Tables moved with keys, indexes and data types chosen deliberately, not whatever the wizard picks
- Pass-through queries and stored procedures for anything heavy
- Fixing the queries that drag a whole table across the network before filtering it
- Record counts and totals reconciled before and after, old back end kept until you’re satisfied
Not sure whether upsizing is the answer? An Access health check will tell you, and it’s the cheaper way to find out. Slowness that turns out to be fixable in place goes to Access performance tuning instead.
Access in the cloud, and what that really means
“Can we move Access to the cloud?” has three honest answers.
1. Data in Azure, Access on the desk. The back end becomes Azure SQL and the Access front end stays as it is. Good on a solid connection at one site. Across the open internet it can be painfully slow unless the queries are reworked first, and that’s the part most quotes leave out.
2. Access hosted, reached remotely. Front end and back end both sit on a hosted desktop (Azure Virtual Desktop or RDS). Identical to users, works from anywhere, no application changes. There’s an ongoing hosting cost to weigh up.
3. Keep the database, add interfaces. Access stays for the office, and the people who are out of it get a browser or mobile version of the parts they need web applications for existing systems
We’ll tell you which one fits, what it costs to run rather than just to build, and what changes for your users. If you already have SQL Server and the question is Azure, see Azure SQL and SQL cloud.
How we keep a migration dull
Nobody can afford to lose a week of orders to a data move.
- We work on a copy. Never the live system.
- Parallel running where it matters, so both are in use for a period and the figures get compared.
- Cutover out of hours or across a weekend, agreed in advance, with a cut-off time for calling it off.
- A written rollback plan before anything starts, and the old back end kept intact.
- Counts, totals and spot checks reconciled afterwards and signed off by someone on your side who knows what the numbers should say.
- We’re still here the week after Access support and development
More on how we run projects: how we work
Case studies
D&M Packaging: quality management, supplier control and production planning
A specialist packaging manufacturer needed its quality management system to handle root cause analysis, supplier non-conformance and complaint investigations properly, alongside capacity planning and shift rotas. Development runs continuously rather than in annual releases, so changes land while they're still relevant.
View case study →Dearson Winyard International: case management, reporting and a client portal
An immigration and right-to-work consultancy runs on documentation, deadlines and client visibility. Ongoing development and support keeps the case management system, management dashboards and client portal working, with staff onboarded in a day and issues resolved before they hold up a case.
View case study →Lilleker Engineering: replacing a legacy job costing system, built around how the business runs
A Rotherham fabrication business needed to get off an ageing job costing system without losing the way it works. The replacement covers jobs, materials, purchase orders, enquiries and invoicing, and most of its best features came out of what users found during testing.
View case study →
Need help with an existing database?
Whether it’s Microsoft Access, SQL Server, a system that needs repairing, or something you need ongoing help with, talk to us.
Send us the details → How we work →