Excel Compatibility Checker: What Those Warnings Actually Mean

You've finally decided to convert your old .xls file to .xlsx. You click File → Save As, pick the new format, and immediately Excel throws up a dialog: "The following features in this workbook are not supported by earlier versions of Excel…" followed by a wall of yellow-warning text you've never read closely.

Most people click "Continue" and hope for the best. Sometimes that works. Sometimes it silently breaks something important and you don't find out until a formula returns the wrong number three weeks later.

This guide explains what each category of Compatibility Checker warning actually means, how to sort the cosmetic noise from the real risks, and what to do about the warnings that matter.

What the Compatibility Checker Is Actually Checking

The Compatibility Checker runs when you save an .xlsx file and want Excel to flag anything that might behave differently in Excel 97-2003 (.xls format) or older versions of Excel. It's designed to help people share files with colleagues on older software.

But when you're migrating from .xls to .xlsx, the checker is working backwards — it's telling you about features that existed in your old file that don't translate cleanly into the new format. That's a different problem than the checker was built to solve, and the warnings can feel confusing as a result.

The checker groups warnings into two severity levels:

• Minor loss of fidelity — The feature works, but may look or behave slightly differently.
• Significant loss of functionality — The feature may not work at all, or data may be permanently altered.

In practice, the checker doesn't always draw the line in the right place. Here's how to read the warnings with more precision.

Warning Categories: The Full Breakdown

Low risk Formatting and Appearance Warnings

These are the most common warnings and almost always safe to ignore during an .xls → .xlsx migration:

• "Some cells or styles in this workbook contain formatting that is not supported by the selected file format."
• "This workbook contains more unique cell formats than are supported."
• Chart formatting, shape effects, or gradient fills that "may not display identically."

What's actually happening: the .xls format has a limit of 4,000 unique cell format combinations. The .xlsx format allows over 64,000. Warnings here usually mean your file uses formatting that exceeded or approached the old limit — moving to .xlsx actually gives you more formatting freedom, not less. The visual difference, if any, is typically invisible.

Action needed: None. Click Continue.

Moderate risk Formula and Function Warnings

These deserve a second look:

• "Some array formulas in this workbook refer to an entire column. In earlier versions of Excel, these array formulas may be converted to #NUM! errors."
• "This workbook contains data in cells outside the row and column limit of the selected file format."
• Warnings about functions introduced after Excel 2003 (IFERROR, COUNTIFS, AVERAGEIFS, etc.).

The row/column limit warning is critical: .xls supports a maximum of 65,536 rows and 256 columns. If your workbook has data beyond row 65,536 or column IV, that data will be silently truncated when saved as .xls. This is usually not a concern when migrating to .xlsx (which supports 1,048,576 rows), but watch for it if you're doing any round-trip saves.

The newer function warnings (IFERROR, XLOOKUP, dynamic array functions) only matter if someone will open the .xlsx in Excel 2003. If your entire organization is on Office 365 or Excel 2016+, these warnings are noise.

Action needed: Check row/column counts. Verify newer functions work correctly after save. Test array formulas.

High risk VBA Macro Warnings

This is where most real-world migrations go wrong:

• "This workbook contains a VBA macro project. The macro project will be lost if you save the file in the macro-free xlsx format."
• "This workbook contains Visual Basic for Applications (VBA) projects and XML maps."

If you see these warnings and save as .xlsx (not .xlsm), your macros are gone. Not broken — gone. The .xlsx format doesn't store VBA code at all. You need to save as .xlsm (macro-enabled workbook) to preserve them.

But saving as .xlsm is only half the battle. VBA macros written for 32-bit Excel (common in .xls files from the 2000s) can fail in 64-bit Office 365 due to PtrSafe declaration issues, API changes, and deprecated functions. The Compatibility Checker won't tell you about those — it'll confirm the VBA was "saved," but whether it actually runs is a separate question.

Action needed: Save as .xlsm, not .xlsx, if macros must be preserved. Then test every macro manually. Better yet, run a pre-migration VBA audit.

High risk ActiveX Control Warnings

ActiveX controls (buttons, combo boxes, spin buttons, list boxes) in .xls workbooks are a separate problem from VBA macros:

• "Some ActiveX controls in this workbook cannot be loaded."
• "This workbook contains an embedded OLE object that cannot be displayed."

ActiveX controls depend on COM registration on the local machine. When a workbook moves from a 32-bit environment to 64-bit Office 365, ActiveX controls frequently fail to initialize — displaying as empty boxes or throwing runtime errors. This is a Windows security and architecture issue, not just a file format issue.

The Compatibility Checker flags these as "minor loss of fidelity," which significantly understates the risk. If your .xls file has an ActiveX-based data entry form, that form may simply stop working after migration.

Action needed: Inventory all ActiveX controls. Test each one in 64-bit Office. Plan replacements for any that fail.

Moderate risk Chart and PivotTable Warnings

• "One or more charts in this workbook use a chart type that is not supported in earlier versions."
• "One or more PivotTables in this workbook contain conditional formatting that may behave differently."

Chart warnings during an .xls → .xlsx migration are usually cosmetic — the chart renders correctly with a slightly updated style. The exception is chart types added after Excel 2003 (Treemap, Sunburst, Box & Whisker, Histogram, Waterfall, Funnel) — those don't exist in .xls and will warn loudly.

PivotTable warnings are more serious. If your PivotTable uses calculated fields with functions introduced after 2003, or is built from an external data connection, behavior after migration should be verified manually.

Action needed: Refresh all PivotTables after migration. Verify chart data is intact.

Low risk Data Validation and Named Range Warnings

Usually safe, but worth a quick check:

• "Some data validation rules will no longer be supported in earlier versions of Excel."
• "Some defined names in this workbook contain formulas that are not supported in earlier versions."

Data validation rules in .xlsx can reference more complex formulas and cross-sheet ranges than .xls allowed. Moving to .xlsx should actually improve validation reliability. If you're seeing this warning on a migration from .xls, it usually means the original validation was hitting edge cases — verify drop-downs and input restrictions still work post-migration.

Action needed: Spot-check data validation on key input cells.

A Decision Framework: Which Warnings to Act On

Warning Type	Real Risk?	Action
Formatting / cell styles	No	Continue
Chart appearance	Usually no	Visual check after save
Newer functions (IFERROR, XLOOKUP)	No (if on Office 365)	Continue
Row/column limit exceeded	Yes — data loss risk	Check row counts before saving
VBA macros	Yes — macros will be lost in .xlsx	Save as .xlsm, test all macros
ActiveX controls	Yes — controls may break	Test in 64-bit Office, plan replacements
PivotTable with external data	Maybe	Refresh and verify after migration
Array formulas (whole-column refs)	Maybe	Test each array formula after save
Data validation	Usually no	Spot-check key input fields

What the Compatibility Checker Won't Tell You

The Compatibility Checker has a frustrating blind spot: it checks format compatibility, not runtime compatibility. It won't warn you about:

• VBA code that uses 32-bit API calls that fail silently in 64-bit Office
• Macros that reference COM objects or external DLLs no longer registered on the machine
• External data connections to servers that no longer exist
• Named ranges pointing to deleted sheets
• Formulas with circular references hidden by the old calculation engine

These issues won't appear in the Compatibility Checker. They'll surface later — in a status bar message, a #REF! error, or a macro that silently does nothing when a user clicks a button.

A proper pre-migration audit checks for all of these. The Compatibility Checker is a starting point, not a safety certificate. For a step-by-step approach that covers everything the checker misses, see our complete migration guide.

The "Minor Loss of Fidelity" Trap

Microsoft's language in the Compatibility Checker tends to minimize risk. "Minor loss of fidelity" sounds like a font might render slightly differently. In practice, it can mean your embedded chart loses its custom data series labels, your ActiveX combo box stops loading, or your carefully configured print area gets reset.

Before migrating any workbook used in production — especially one with financial calculations, automated reports, or data entry forms — do a full functional test after the save. Don't rely on the Compatibility Checker to have caught everything important.

Quick Checklist: What to Verify After Every Migration

1. Open the migrated file and check the status bar — any recalculation errors?
2. Click through all tabs. Do named ranges resolve? Does navigation work?
3. Trigger every macro. Do they run without errors?
4. Click every ActiveX control. Do buttons, dropdowns, and spinners respond?
5. Refresh all PivotTables. Do row counts match the source data?
6. Check data validation — do dropdown lists populate correctly?
7. Print preview a report sheet — are headers and page breaks intact?

This takes 10–15 minutes per workbook. For a large batch, automate it with a test script — or use LegacyLeaps's automated validation to flag issues before they hit users.

← Back to all posts