How to Compare Excel Workbook Versions Before ERP Migration

Spreadsheet discovery is not always a one-time exercise. During an ERP, CRM or application transformation, operational workbooks can continue to change after requirements have been captured.

A migration team may analyse one version of a workbook during discovery, while business users continue working from a newer copy containing changed formulas, adjustments or additional logic.

If those differences are not identified, the implementation team can end up designing and testing the new system against requirements that are already out of date.

A workbook can look structurally identical while the logic inside it has changed.

Why workbook version comparison matters during migration

Operational spreadsheets rarely remain completely static during a long transformation programme. Business users may continue making changes because the spreadsheet is still supporting day-to-day operations.

Changes might include:

• adjusted pricing formulas
• new thresholds
• changed calculations
• updated status logic
• new fields or columns
• additional worksheets
• removed outputs
• manual workarounds introduced after discovery

The migration risk is not simply that the files are different. The important question is:

What changed, why did it change, and does that change affect something the new system must preserve?

The file can look the same while the business logic changes

Two spreadsheet versions may contain:

• the same number of worksheets
• the same number of formulas
• the same visible dashboard
• the same file structure

Yet individual formulas can still be different.

That difference may be intentional, accidental or temporary. Either way, it should be understood before migration or approval.

What should be compared between workbook versions?

1. Worksheet structure

Compare whether worksheets were:

• added
• removed
• renamed
• reorganised

A removed sheet can matter if another part of the workbook depended on it or if it represented a business process that now needs to be handled elsewhere.

2. Tables and fields

Fields added or removed between versions may indicate a changing requirement, new input, new output or changing source data.

Examples include:

• new customer classifications
• additional approval fields
• new cost components
• removed reporting columns
• new operational statuses

3. Formula logic

Formula comparison is one of the most important parts of workbook change analysis.

A useful comparison should identify:

• added formulas
• removed formulas
• changed formulas
• changed formula locations
• logic changes inside existing calculations

4. Cross-sheet dependencies

A change in one worksheet can affect calculations elsewhere in the workbook.

This is why formula changes should not be assessed in isolation.

5. Business-facing outputs

Changes affecting outputs deserve particular attention where the spreadsheet supports:

• pricing
• costing
• financial reporting
• operational planning
• customer decisions
• management dashboards

6. Business rules

A formula change may represent a change in the underlying business rule.

For example, if a pricing formula changes from:

the implementation team should not simply record a formula difference. They should ask whether the business requirement itself has changed.

Example: seven formula changes without a formula-count change

In an IC-Flow workbook comparison example, two versions contained the same number of formulas:

The formula count alone therefore suggested no change, while detailed comparison showed that seven calculations had actually been modified.

This is a useful example of why workbook change review should look beyond high-level file statistics.

What does a formula change mean for an ERP project?

Not every formula change represents a major migration risk.

But each material change should be assessed in context.

The project team may need to ask:

• Was the change intentional?
• Who approved it?
• Does it reflect a new business rule?
• Does it affect an important output?
• Has the migration requirement already been documented?
• Does the target-system design need updating?
• Should an existing UAT test be repeated?

Version comparison can support change control

Workbook comparison can be particularly useful after the initial discovery phase.

This turns spreadsheet comparison into part of migration change control rather than a standalone technical exercise.

Workbook comparison can improve UAT

If important spreadsheet logic changes during the implementation, previously agreed test cases may no longer be sufficient.

A useful change review can therefore identify where outputs should be re-tested.

For example:

Why file names are not enough

Spreadsheet version control is often informal.

Teams may encounter files named:

• Pricing.xlsx
• Pricing_FINAL.xlsx
• Pricing_FINAL_v2.xlsx
• Pricing_NEW.xlsx
• Pricing_Approved_FINAL.xlsx

File names alone do not reliably explain what changed.

Structured comparison is more useful because it examines the actual workbook structure and logic.

Questions to ask when a newer workbook appears

1. Which version is currently used by the business?
2. Who owns the workbook?
3. What changed since the previous version?
4. Were any formulas changed?
5. Were fields, tables or worksheets added or removed?
6. Do changed formulas influence important outputs?
7. Do the changes represent new business requirements?
8. Does the target-system configuration need updating?
9. Should any UAT scenarios be repeated?
10. Which version should form part of the migration evidence?

How IC-Flow supports workbook version comparison

IC-Flow can compare workbook versions to help project teams understand structural changes, formula changes and potential business impact before approval or migration.

The comparison can help surface:

• version-to-version changes
• added and removed sheets
• added and removed fields
• formula-count differences
• changed formulas
• structural differences
• potential business-impact considerations
• review recommendations

Used alongside IC-Flow's workbook analysis, Business Rule Register and Migration Readiness Assessment, version comparison can help maintain traceability while spreadsheet logic continues to evolve.

From workbook comparison to migration evidence

The goal is not simply to identify that two files are different.

The useful outcome is understanding whether the differences matter to the transformation programme.

Before migration sign-off, check what changed

Spreadsheet discovery should answer:

What does this workbook do?
What depends on it?
What changed?
What must be preserved?

If an important operational workbook has changed since discovery, it may be worth comparing the versions before configuration, migration or UAT decisions are finalised.