Planning a Legacy File Migration Project — The IT Manager's Playbook

Most legacy file migration failures aren't technical. The conversion tools work. LegacyLeaps converts the files. The VBA gets updated. The test environment is fine.

What goes wrong is project management. Files that were supposed to be included weren't. Users weren't told about the path change. The rollback plan wasn't ready when something unexpected happened. A department head didn't know the migration was happening and reported "everything broke" — because their path shortcuts still pointed to the old .xls files.

This playbook is the project planning layer that sits on top of the technical migration. Follow it and you won't have those conversations.

Before You Start: Scope and Stakeholders

Define scope precisely

Before anything else, answer these questions in writing:

• Which file systems are in scope? (Specific network shares, individual machines, cloud storage?)
• Which file types? (.xls only, or also .xlsm, .mdb, .accdb from old versions?)
• Are archived files included, or only active files?
• What's the cutoff date? (Files not modified in 5+ years may not need migration)
• Who owns each file set?

Scope creep is the most common reason migrations run over budget and time. Define it before you start, get sign-off from stakeholders, and document what's explicitly out of scope.

Identify stakeholders

Legacy file migrations touch more people than IT usually expects. Map your stakeholders:

Stakeholder	Interest	Communication needed
Department heads	Their files still work, no disruption	Timeline, what changes for their team
End users	Files are where they expect, macros still run	New file paths, what to do if something breaks
Finance/Compliance	Audit trail for migrated files	Migration log, before/after file inventory
Application owners	Apps that reference .xls or .mdb file paths	Path changes, timeline for updates
Help desk	What to expect in post-migration support tickets	Known issues, escalation path

Phase 1: Inventory and Risk Assessment (Week 1)

1 Run the automated file scan

Use LegacyLeaps's free scanner on every file path in scope. Output: complete file list with format, size, last-modified date, macro presence, ActiveX controls, external links.

This scan output is your project foundation. Don't skip it. Don't rely on manual estimates. The scan takes minutes and gives you the data you need for every subsequent decision.

2 Classify and triage

Sort the scan output into three tiers:

• Tier 1 — Simple: No macros, no external links, straightforward format conversion
• Tier 2 — Complex: VBA macros, ActiveX controls, external workbook references — require macro-preserving migration
• Tier 3 — Manual review: Files with unusual complexity, broken references that predate the migration, or very large macro codebases

3 Identify business-critical files

Within Tier 2 and Tier 3, identify which files are actively used in production processes. These get extra attention: pre-migration testing, owner notification, and pilot testing before batch processing.

Phase 2: Pilot Migration (Week 2)

Before touching production files, run a controlled pilot on a representative sample:

• Select 20-30 files — a mix of all three tiers, including the most complex business-critical files
• Run migration on copies (never originals) in a test environment
• Validate each output file: macro module count, formula results, external link resolution
• Have the file's owner open and test the converted file in their normal workflow

The pilot catches tooling issues, unexpected file structures, and stakeholder surprises before they affect the full migration. If the pilot uncovers a problem type, you can adjust the migration approach before processing hundreds of files with the same issue.

Phase 3: Batch Migration (Weeks 3-4)

With a validated pilot, run the full batch migration tier by tier:

1. Tier 1 first — PowerShell COM for simple files if volume is large, LegacyLeaps for the rest
2. Tier 2 next — LegacyLeaps batch mode for macro-containing files
3. Tier 3 individually — manual attention for flagged complex files

Run batch jobs outside business hours for production file systems. Keep the migration log for each batch — file input, output, warnings, errors. This is your audit trail and your diagnostic tool if something surfaces post-migration.

Maintain originals throughout

During the migration phase, keep all original .xls and .mdb files in an archive location. Don't delete or move them until cutover is validated. This gives you instant rollback if needed.

Phase 4: Validation (Week 4)

Don't skip validation. Don't abbreviate it under schedule pressure. Broken files discovered in production cost more to fix than time spent validating.

Automated validation

• Macro module count comparison (source vs output) for all Tier 2 files
• File size sanity check — output files dramatically smaller or larger than source warrant investigation
• External reference resolution check on all files with external links

User acceptance testing

• Ask owners of business-critical files to run their normal workflow on the converted file
• Target 5-10 representative users across departments
• Give them a simple checklist: open the file, run the primary function, check three key values, report any differences

Application testing

• Test any application that references migrated file paths (ERP integrations, reporting tools, scheduled imports)
• Update application configs that hard-code old file paths

Phase 5: Cutover and Communication

The communication plan

Users who aren't told about a migration will report it as an incident. Send communications at three points:

1. One week before cutover — what's changing, when, what users need to do (usually: update shortcuts/bookmarks to new paths)
2. Day of cutover — it's happening today, here's what to do if something breaks
3. One week after cutover — migration complete, reminder of support channel for issues

Cutover execution

1. Move converted files from staging to production paths during off-hours
2. Update any redirects, shortcuts, or application configs to point to new file paths
3. Leave original files in archive (do NOT delete yet)
4. Notify help desk of known post-migration issues and escalation path

Rollback plan

Document and brief the team on the rollback procedure before cutover. If a production issue surfaces in the first 48 hours, can you restore the original files quickly?

• Archive location: [document where originals are stored]
• Rollback trigger: [define what constitutes a rollback-level issue vs. a support ticket]
• Rollback owner: [who authorizes and executes a rollback]
• Rollback timeline: [originals available for 30 days, then cleanup]

The Full Project Checklist

Related Reading

• How to Convert .xls to .xlsx at Scale Without Losing a Single Macro
• The IT Manager's Buyer's Guide to Bulk Excel File Conversion
• Backup Strategies Before a Windows Upgrade
• Excel Migration Validation Checklist

Part of the Windows Upgrade Survival Guide for Office Files.

← Back to all posts