Migration planning
A practical 12-step checklist to prepare your Access database for migration with lower risk and clearer scope.
Most MS Access migration failures trace back to skipped preparation,not missing technology. Teams rush to pick SQL Server, Azure, or a web stack before they understand what the database actually does: which workflows are business-critical, where VBA hides policy, and which reports executives still trust on Monday morning. This checklist gives IT leaders, operations managers, and internal developers a structured pre-migration audit you can run in two to three weeks, before you sign a statement of work or commit to a cutover date. Treat it as a risk-reduction exercise, not paperwork. Each step produces artifacts your migration partner needs for accurate scope, timeline, and pricing.
Access databases often grow organically over ten or fifteen years. The original developer may have left, documentation may be thin, and “tribal knowledge” may live in one power user’s head. When leadership finally approves modernization, vendors receive a vague brief: “move it to the cloud.” Without a checklist, discovery happens during development,when change orders are expensive and timelines slip.
A disciplined checklist forces alignment between business and IT on what must be preserved, what can be retired, and what “done” means at go-live. It also surfaces blockers early: unsupported ODBC drivers, Excel export macros that finance relies on, or a nightly job that pushes data to a warehouse. Those items belong in a migration plan, not in a surprise email two weeks before cutover.
If you are evaluating partners, share checklist outputs during the RFP. Teams that provide transparent pricing bands and phased statements of work can quote more accurately when they receive a real inventory,not just a file size.
Export a complete object list from Access (Navigation Pane or Database Documenter). For each form and report, record: primary users, frequency of use, and whether it is read-only or transactional. Flag subforms, tab controls, and combo boxes that depend on lookup tables,those drive web UI complexity.
Queries deserve equal attention. Pass-through queries, UNION queries, and nested subqueries often encode business rules that never appear on a form. Macros and embedded macros should be listed separately; many “simple” buttons trigger chains that must be recreated as web actions or API calls.
Classify every object as critical (revenue or compliance), active (weekly use), or legacy (candidates to retire). This classification becomes the backbone of a phased rollout and prevents paying to rebuild screens nobody uses.
| Artifact you produce | What it prevents | Who consumes it |
|---|---|---|
| Object inventory with usage tiers | Scope creep from “hidden” screens | PM, architect, QA |
| VBA / macro logic map | Lost validations at go-live | Developers, business analyst |
| Data dictionary + FK diagram | Broken relationships after upsize | DBA, migration engineer |
| Integration register | Cutover failures with ERP/email | DevOps, integration lead |
| UAT script per critical workflow | Sign-off disputes | Business owner, support |
Open the VBA editor and search for event handlers: Form_BeforeUpdate, AfterInsert, button clicks, and timer-driven routines. Document each rule in plain language (“cannot close order if line items sum ≠ header total”). Note whether the rule is duplicated in table constraints or only in code,web migrations must pick a single source of truth, usually the database or API layer.
Email via Outlook automation, file exports, and shell commands are frequent migration hotspots. Decide whether to replace them with platform services (SendGrid, blob storage, queue workers) or keep a thin integration layer. If your team plans a full web conversion, our Access to web app approach preserves rules in maintainable server-side logic rather than scattered client scripts.
Want a third-party review of your inventory before you commit budget?
Book a free migration audit callRun row counts per table and identify tables approaching Access limits or exhibiting bloat. Check link tables to SQL backends if you already use a hybrid model. Use simple queries to find orphan foreign keys, nulls in required business fields, and duplicate natural keys (customer code, SKU, employee ID).
Document attachment fields, multi-value fields, and non-standard types,these do not always map cleanly to SQL or web ORMs. Plan remediation scripts or one-time cleanup windows. If your target is SQL Server, review our Access to SQL Server path for upsizing considerations before you freeze schema.
List active users, locations (office vs. remote), and role groups. Access security databases and ad hoc “who can open which form” conventions need to become an explicit role matrix for web or SQL security. Include service accounts, batch users, and external consultants.
Note compliance requirements: audit trails, field-level restrictions, and retention policies. A web app can enforce row-level security more consistently than file-based Access, but only if requirements are captured up front.
Identify linked tables, ODBC connections, Excel imports, Power Automate flows, and scheduled Windows tasks that touch the ACCDB or MDB. Map direction of data flow and frequency. For each integration, define whether it must work on day one of migration or can move in phase two.
Short-term continuity sometimes means hosting Access online while a web or SQL backend is built in parallel,include that option in your checklist if remote users cannot wait six months for a full rewrite.
By this point you have enough facts to compare paths: SQL backend with Access front-end, hosted desktop, full web conversion, or hybrid. Score each on time-to-value, security, recurring cost, and developer skill fit. Avoid choosing a path because it is trendy; choose because it matches user behavior and risk tolerance.
Engage stakeholders with a one-page decision summary. Link budget discussions to realistic web conversion cost drivers so finance understands why a ten-form pilot is cheaper than a big-bang rewrite.
Select one high-value, medium-complexity workflow for a pilot,order entry, case intake, or inventory adjustment are common choices. Define measurable outcomes: page load time, error rate, time-on-task versus Access, and support ticket volume. Set a fixed pilot duration (four to six weeks is typical) and a go/no-go gate before phase two funding.
Build a release roadmap that sequences remaining modules by business priority, not by developer convenience. Each phase should end in production value, not just technical milestones.
Ready to turn your checklist into a scoped migration plan?
Request a phased roadmap workshopCutover is a business event, not a technical flip. Agree on a freeze window, final delta sync process, and who authorizes go-live. Prepare rollback criteria: if critical workflows fail UAT or performance degrades beyond agreed thresholds, you revert to Access or hosted desktop without debate.
Train support staff with runbooks for the first two weeks. Schedule hypercare hours and daily standups with business owners. Archive the legacy database read-only for audit,not as the live system of record.
Completing this twelve-step checklist does not guarantee a painless migration, but it dramatically improves forecast accuracy and stakeholder trust. When you are ready for delivery, our MS Access migration services team uses these same artifacts to build fixed-scope pilots and phased programs tailored to your inventory,not generic templates.
For end-to-end migration delivery, explore our MS Access Migration Services.
For a typical mid-size Access application (30–80 forms/reports combined), allow two to three weeks of part-time effort from a business analyst plus someone who knows the database internals. Larger systems with heavy VBA or many integrations may need four weeks. Rushing this phase is the most common reason migration budgets inflate mid-project.
You can defer low-usage reports, but you should still inventory them. Unused reports sometimes contain validation logic or queries referenced elsewhere. Mark each item as critical, active, or legacy so your partner can phase work intelligently rather than discovering hidden dependencies during UAT.
Fix structural issues (orphan keys, duplicate natural keys, inconsistent codes) before cutover. Cosmetic cleanup can happen in parallel, but migration validation is far simpler when source data already meets the rules your web or SQL target will enforce.
Even small systems benefit from a one-workflow pilot. It validates architecture, performance, and user acceptance with limited blast radius. Pilots also produce realistic effort metrics for the full rollout.
Assign a single business owner (department lead or product owner) and a technical counterpart (internal Access developer or IT). The business owner prioritizes workflows; the technical lead extracts schema, VBA, and integration facts. External partners can facilitate workshops but should not be the only source of process truth.