You've got the mandate: migrate all .xls files to modern formats before the next Windows rollout. The file server shows 847 .xls files. Another scan finds 200 more on user desktops. You have four weeks and one IT person.
This is the guide for that project. We'll cover the full workflow — from discovery to validation — including the decisions that matter most and the mistakes that turn a two-week project into a two-month one.
Before we get into the process, let's establish why this requires a structured approach rather than a PowerShell loop.
The macro trap. Every .xls file that contains VBA macros must be saved as .xlsm, not .xlsx. Saving a macro-containing file as .xlsx silently deletes all VBA code. A naive batch conversion that saves everything to .xlsx will destroy macros in any file that had them — with no warning and no log of what was lost.
The PtrSafe problem. Many .xls files contain VBA that calls Win32 API functions using 32-bit Declare statements. These statements require the PtrSafe keyword to compile on 64-bit Office. A file that converts from .xls to .xlsm without this fix will fail to open with a compile error on 64-bit machines.
External connections. Some .xls files pull data from other .xls files, ODBC sources, Access databases, or SQL Server. After conversion, those connection strings may need updating. Files with connections need individual review, not batch automation.
Large files. Files over 500MB need special handling. They take longer to process, are more likely to have memory issues during conversion, and warrant verification against the original post-conversion.
A proper bulk migration handles all of these. A naive batch conversion creates a new set of problems for users to discover one by one.
Scope: all file servers, shared drives, SharePoint document libraries, and a sample of user workstations. You cannot migrate what you haven't found.
What to collect: Full path, filename, file size, last modified date, last accessed date.
Filter out: Files not accessed in 3+ years (consider archiving instead of migrating), files owned by departed employees (flag for manager review), files in backup or archive directories (don't migrate backups).
Output: Complete file inventory spreadsheet, sorted by size and last access date.
This is the phase that separates professional migrations from disasters. Every file needs a classification before conversion begins.
Category A — Standard conversion (.xlsx): No VBA macros, no external connections, under 500MB. Safe for automated batch conversion.
Category B — Macro conversion (.xlsm): Contains VBA macros, no complex external connections, under 500MB. Automated conversion with PtrSafe fix pass.
Category C — Manual review required: Large files (500MB+), external data connections, ActiveX controls, links to other .xls or .mdb files, or complex VBA with Shell/CreateObject calls. These need individual attention before conversion.
Category D — Archive / don't migrate: Not accessed in 3+ years, owned by departed employees, in backup directories. Preserve as-is in a read-only archive location.
Schedule the automated conversion to run overnight on a dedicated machine. For 1,000 files, expect 4–8 hours of processing time depending on average file size.
For Category A (no macros): Open → Save As .xlsx → Close. Simple and fast.
For Category B (with macros): Open → scan VBA modules for Declare statements → add PtrSafe where missing → remove MISSING references → Save As .xlsm → Close.
Conversion log: Record for every file: original path, target path, original format, target format, macro count, Declare statements found/fixed, references fixed, conversion status (success/warning/error), processing time.
Never delete originals during this phase. Convert to a staging directory first.
Budget 30–90 minutes per file for Category C, depending on complexity. These files need a human reviewing each one.
Large files: Process on a machine with 32GB+ RAM. Verify record counts and formula outputs against the original before and after conversion.
Files with external connections: Update connection strings to reference converted files (if the source was also an .xls, it needs to be converted first). Test all data refreshes after conversion.
Files with ActiveX controls: Identify which controls are used. Check if 64-bit versions are available. Plan replacements for 32-bit-only controls before conversion.
Files linked to Access databases: Ensure the linked .mdb has been (or will be) converted to .accdb. Update the Excel connection string after both conversions are complete.
Do not skip this phase. Conversion errors that slip through to users become support tickets, lost work, and credibility problems for the IT team.
Automated checks: File count matches (every source file has a corresponding converted file). No conversion errors in the log. File sizes are in the expected range (converted .xlsx is typically smaller than original .xls; converted .xlsm should be similar size).
Spot-check sample (5–10% of files): Open converted file. Open original file side by side. Verify: same sheet names, same row/column counts on key sheets, formulas calculate to same values, formatting matches, charts render correctly.
Macro validation (all Category B): Open in 64-bit Excel. VBA editor should show no compile errors. Run each macro once and confirm no runtime errors.
| Phase | Duration | IT Hours | Notes |
|---|---|---|---|
| Discovery | 0.5–1 day | 2–4 hrs | Mostly automated script runtime + review |
| Triage | 0.5–1 day | 3–6 hrs | Review inventory, classify each file |
| Automated conversion | 1 overnight run | 1–2 hrs setup | Runs unattended 4–8 hrs |
| Manual processing (Cat. C) | 1–3 days | 8–24 hrs | Depends on Cat. C file count and complexity |
| Validation | 0.5–1 day | 3–5 hrs | Spot checks + automated log review |
| Deployment | 0.5 day | 2–3 hrs | Archive originals, replace in production |
| Total | 1–2 weeks | 19–44 hrs | For 1,000 files with ~20% Category C |
Compare this to manual conversion: 1,000 files × 5 minutes each = 83 hours of click-through work. The structured approach with automation cuts IT hours by 50–75% and eliminates the manual error rate.
The scan phase, triage classification, batch conversion with macro detection, PtrSafe fixes, and per-file conversion log — all built in. IT sets up the job, runs it overnight, reviews the report in the morning.
See IT Teams FeaturesThe single most common mistake. Someone runs a PowerShell loop that does Save As .xlsx on every file. Every file that had VBA macros now has an .xlsx with the macros deleted. Users complain that "something's wrong" with dozens of files. IT spends three weeks debugging.
Fix: Always scan for macro content first. Files with VBA must go to .xlsm.
Conversion problems discovered after deployment are much harder to recover from if the originals are gone. Keep every original .xls file in a read-only archive location for at minimum 90 days after deployment.
Discovery often turns up thousands of .xls files, but many are old reports, one-time exports, or files from departed employees. Spending IT hours migrating a 2009 budget model nobody touches is wasted work. Filter by last access date and confirm with department heads before migrating low-activity files.
Files that reference other files by path — =C:\Reports\2024\budget.xls!Sheet1!A1 — will break when the source file moves or renames. After converting source files, search for .xls references in the converted files and update them.
The validation phase is the one that gets cut when a project runs behind schedule. This is exactly backwards — if the conversion had problems, the validation phase is when you find out. Deploy first, validate later means users find the problems instead of IT.
The conversion log will show failures. Common causes: file is password-protected (you need the password), file is already open by another user (schedule conversion during off-hours), file is actually corrupted (try Compact and Repair for .xls via Excel's repair mode), file extension was renamed but isn't actually an Excel file.
Excel's Edit Links dialog (Data > Edit Links) shows all external references and their current status. After conversion, "error" status links need to be updated or broken. If the source file has also been converted, update the path. If the source no longer exists, the link should be converted to a static value.
Some .xls files depend on COM add-ins that may not be installed on the conversion machine. These files will open with errors during conversion. Either install the add-in on the conversion machine, or flag them for manual conversion on a machine where the add-in is present.
SSIS packages, scheduled tasks, Python scripts, and other automation may reference .xls files by exact path and extension. After conversion, these need to be updated to reference the new .xlsx/.xlsm files. Coordinate with application owners before converting files used in automation workflows.
LegacyLeaps's done-for-you service handles bulk migrations end-to-end: discovery, triage, conversion, VBA fixes, validation, and deployment report. Flat rate based on file count. 100% money-back guarantee.
Get a QuotePractical fixes for legacy Excel and Access problems. No spam.