When a single user has a broken Excel file, the answer is straightforward: fix it. When an IT director gets a mandate to migrate 800 legacy Office files across 12 departments before the next Windows 11 rollout wave, the answer is a project.
This guide is for that project. It covers the five phases of a disciplined enterprise bulk migration — from discovery to verified replacement in production — and the specific decisions that determine whether a migration runs smoothly or turns into a months-long firefight.
The files in scope: .xls (Excel 97–2003), .xlsm (macro-enabled workbooks with compatibility issues), .xla (Excel add-ins), .mdb (Access 97–2003), and .accdb files with VBA or ActiveX controls that need remediation before Windows 11 24H2.
Before the playbook, it's worth naming the patterns that cause enterprise legacy file migrations to drag on or produce expensive surprises.
Inventory gaps. Most IT teams underestimate their legacy file count by 40–60%. Files accumulate on network shares, in departmental SharePoint sites, on users' local drives, and in legacy application directories that weren't set up by IT. A migration that doesn't start with a complete inventory is a migration that will be surprised midway.
No triage = no prioritization. Treating every legacy file as equivalent means either doing too much (spending hours on an archival file nobody touches) or doing too little (missing the critical billing database because it wasn't labeled as such). Triage separates the 20% of files that represent 80% of risk from the long tail that can wait.
Conversion without verification. Converting a file from .xls to .xlsx doesn't guarantee the output is correct. VBA that worked in 32-bit Excel may produce different results in 64-bit Excel. Access queries that ran against Jet may behave differently against ACE. Any migration that doesn't include a verification step is a migration that's shipping undetected errors into production.
Big bang vs. phased approach. Migrating everything at once maximizes scheduling complexity and risk surface. Migrating in priority-ordered phases lets you validate the process on lower-stakes files before applying it to mission-critical ones.
LegacyLeaps offers volume pricing and a done-for-you option for IT departments with 50+ files. We handle the conversion; you handle verification with the business owners.
See IT Team PricingThe goal of Phase 1 is a complete list of every legacy Office file in scope, with enough metadata to feed the triage phase.
For each file, record: full file path, format (extension), file size, date last modified, date last accessed (if available from the file system), and macro/VBA presence. LegacyLeaps's scanner captures all of this automatically and exports to CSV for manipulation in Excel or import into a project tracker.
A typical mid-sized organization (500–2,000 employees) with legacy Office infrastructure will have:
| File type | Typical count | Complexity range |
|---|---|---|
| Plain .xls (no macros) | 200–800 | Low |
| .xls with VBA macros | 50–200 | Medium–High |
| .xlsm / .xlam add-ins | 5–30 | High |
| Plain .mdb (no VBA) | 10–60 | Medium |
| .mdb with VBA / ActiveX | 5–30 | High |
| .mdb with external linked tables | 2–15 | Very High |
The exact numbers depend heavily on how long your organization has been using legacy Office software and how disciplined your file management has been. Organizations with more than 15 years of legacy file accumulation typically find 2–3× more files than they expected.
Phase 2 converts the raw inventory into a prioritized migration queue. Two factors drive priority: complexity (how hard is the conversion?) and business impact (what happens if this file breaks in production?).
| Tier | File types | Conversion effort |
|---|---|---|
| Tier 1 — Simple | Plain .xls, plain .mdb with no VBA or linked tables | Automated — minutes per file, no review required |
| Tier 2 — Standard | .xls with VBA that uses no Win32 API calls; .mdb with forms but no ActiveX | Automated with review — run conversion, spot-check macros |
| Tier 3 — Complex | .xls with Win32 API declarations; .mdb with ActiveX controls or linked external tables | Manual remediation required — flag for specialist review |
| Tier 4 — Evaluate | .mdb files that are functionally a small application, not just a data store | Consider AccessLeap modernization rather than format conversion |
Your priority order should be: Critical + Tier 3 first (hardest and most important), then Critical + Tier 1/2, then Active files in tier order, then Archival last. The temptation is to do easy files first to show progress — but that leaves your highest-risk files for last, when you're most tired and most likely to cut corners on verification.
With a prioritized queue, migration proceeds in batches. Batch size should be manageable for verification in the same sprint — don't convert 200 files if you can only verify 30 per week.
LegacyLeaps converts .xls files to .xlsx with full formula preservation. For files with VBA, it audits the macro code for 32-bit API dependencies and flags any Declare statements that need PtrSafe updates. The conversion report lists every flagged item so your team knows exactly what requires manual review before deployment.
For Excel add-ins (.xla, .xlam), test in a sandboxed Excel 365 instance before deploying to users. Add-ins that interact with Office COM interfaces may need additional remediation beyond what automated conversion can handle.
Access migration has two distinct paths depending on what the database actually does:
Path A: Format migration (.mdb → .accdb) — For databases that are primarily data stores with some forms and reports, converting to .accdb resolves the Jet/ACE compatibility issue and modernizes the format. LegacyLeaps handles this conversion, preserving queries, forms, reports, and VBA modules.
Path B: Application modernization — For .mdb files that are essentially business applications — multi-user, with VBA automation, forms, reports, and embedded logic — format conversion alone may not be the right answer. These databases often have design patterns that don't translate cleanly to modern Access (.accdb), and the ongoing maintenance burden remains. AccessLeap converts these legacy Access applications to modern web apps, eliminating the Access dependency entirely and making the application accessible from any browser without an Office installation.
How to tell which path to take: If the database has more than 5 forms, more than 2,000 lines of VBA, or is used by more than 3 concurrent users, evaluate Path B. Format migration for a complex Access application often produces a converted file that still needs significant remediation — the format changes but the fragility doesn't.
Verification is the step most migrations skip and most regret skipping. The goal isn't to test everything — it's to confirm the files that matter most are producing correct output.
Verification should be done by the business owner, not IT. IT doesn't know what "correct output" looks like for a finance department's quarterly accrual spreadsheet — finance does. IT's job in the verification phase is to set up the comparison environment and document what was tested. The business owner signs off.
Once a converted file passes verification, it goes into production.
_archive_YYYYMMDD to the filename (e.g., payroll_calc.xls → payroll_calc_archive_20260415.xls)./finance/archive/legacy/). Do not delete it.Keep original files for a minimum of 90 days post-conversion. Most file failures surface within the first 30 days of active use. After 90 days without issues, the original can be moved to cold storage or deleted per your data retention policy.
After Phase 5 for your critical and active files, you'll have a long tail of archival files — .xls spreadsheets that haven't been touched in years, .mdb databases that were built for a project that ended in 2018. These don't need to be migrated urgently, but they do need to be addressed eventually.
Options for archival files:
| File count | Complexity mix | Recommended approach | Typical timeline |
|---|---|---|---|
| Under 50 files | Mostly Tier 1–2 | Self-service with LegacyLeaps | 1–2 weeks |
| 50–200 files | Mixed | Self-service + IT lead for Tier 3 | 3–6 weeks |
| 200–500 files | Mixed | LegacyLeaps done-for-you + IT verification | 4–8 weeks |
| 500+ files | Mixed with significant Tier 3/4 | LegacyLeaps done-for-you + AccessLeap for complex Access | 8–16 weeks |
These timelines assume dedicated part-time IT resource (one person, 20–30% of their time) plus business-owner availability for verification. If verification is the bottleneck — which it usually is — the timeline extends accordingly.
For IT directors who need to build a business case, the core argument is straightforward: reactive legacy file remediation costs more than proactive migration, and the risk of a critical file breaking during a month-end close or audit is an unacceptable operational risk.
Useful framing for the executive sponsor:
LegacyLeaps's free scan gives you the inventory you need to build a project plan and a business case. Run it on a sample share to see what you're working with before committing to a full rollout.
See IT Team Options Try Free ScannerPractical fixes for legacy Excel and Access problems. No spam.