SAMPLE REPORT — “Hartwell Fabrication Ltd” is a fictional company; all data on this page is synthetic. This is the exact structure, depth and tone of a real Evidale assessment.
Migration Readiness Assessment

HFL_Production_Planner_v13.xlsm

Prepared for Hartwell Fabrication Ltd — sheet-metal fabrication, West Midlands, UK (fictional sample client)

Reference — EVD-2026-S01 (sample)
Date — 4 August 2026
Prepared by — Evidale · hello@evidale.io
Service — Assessment, €790 flat
Input received — anonymised workbook copy + 9 written answers
Turnaround — 6 business days

1.Executive summary

Hartwell Fabrication Ltd (“HFL”, ~42 staff) plans production, costs jobs and books dispatches through a single Excel workbook, HFL_Production_Planner_v13.xlsm, built and maintained since 2012 by an operations manager who retired in 2025. Roughly a dozen people use it daily; nobody currently at HFL can modify the VBA with confidence. The question we were asked: keep it, fix it, or replace it — and at what cost?

Verdict
Partially Migrate
KeepStabilizePartially MigrateReplace
Confidence: 80%. The runner-up was Stabilize (15%); a full Replace is not justified by the evidence (5%) — the costing core is sound and encodes rare shop-floor knowledge.

In one paragraph: the workbook is not dying — it is concentrated. Three of its six jobs (order intake, dispatch emailing, archiving) are exactly the fragile, integration-heavy parts that break when Windows, Office or one hard-coded path changes, and they are the parts that will fail first — the dispatch email module already depends on classic Outlook automation that new Outlook deployments do not support. The costing engine, by contrast, is battle-tested and correct (we verified it against 12 golden cases). The rational move is to stabilize now (15–20 h), move intake and dispatch to boring managed services (40–60 h), and leave costing in Excel behind a cleaned-up interface — revisiting a full rebuild only if HFL's volume or team changes.

Top 5 risks (of 10 identified — full register in §5)

#RiskSeverityWhy it matters now
R1Key-person risk: sole author retired, no documentationHIGH Any non-trivial failure is currently unrecoverable in-house
R3Dispatch emails via classic Outlook COM automationHIGH New Outlook does not support this; one IT rollout away from stopping dispatches
R2Hard-coded personal paths (author's desktop) in the import chainHIGH Order import silently depends on a leaver's profile folder being recreated
R5No versioning; parallel “v13_FINAL_(2)_USE_THIS” copies circulatingMED Divergent copies are already producing conflicting numbers between teams
R414 of 86 named ranges broken (#REF!), 2 in the costing pathMED Errors are being masked by On Error Resume Next — failures will be silent

Recommended path and cost

Estimates are ±30% and assume written access to one HFL power user for questions. Detailed breakdown in §8.

2.Scope and method

What we received: one anonymised copy of the workbook (customer names and prices masked per our checklist — the anonymisation did not affect the analysis), plus written answers to nine intake questions from HFL's operations lead.

What we did: programmatic inventory of every sheet, formula, named range, external reference and VBA procedure; manual code review of all 13 VBA components; reconstruction of the six “jobs” the workbook performs; verification of the costing logic against 12 golden cases supplied by HFL; risk scoring; architecture options.

What we did not do: we did not run the workbook against live systems (ODBC, Outlook, network shares are outside an anonymised copy), did not review surrounding processes, and did not audit security beyond the workbook itself. Findings that depend on HFL's live environment are marked as assumptions.

3.What this workbook actually is

Twelve years of accretion have produced a system with six distinct jobs. Naming them is the single most useful step in deciding its future, because the verdict differs per job:

JobWhere it livesHealthDirection
1. Order intake (CSV import from ERP export)modImport + OrdersFragileMigrate
2. Daily production planningmodMain + Dashboard/CapacityWorkableKeep, simplify
3. Job costingmodCosting + JobCosting/BOM_Lookup/MaterialsSoundKeep, contain
4. Dispatch emailingmodEmail (Outlook COM)FragileMigrate
5. ArchivingmodArchive + archive sheetsWorkableMigrate with #1
6. Label/paperwork printingmodPrintWorkableKeep, fix path

4.Inventory

4.1 Workbook metrics

MetricCountNotes
Sheets1917 visible + 2 hidden (Scratch, zOld_Rates)
Formulas≈41,200of which ≈1,870 volatile (OFFSET, INDIRECT, NOW, TODAY)
Named ranges8614 broken (#REF!) — 2 referenced from the costing path
VBA components139 standard modules, 3 sheet modules, ThisWorkbook — ≈3,380 LOC, 47 procedures
External dependencies6see §4.4 — 2 confirmed dead, 2 environment-fragile
Array formulas (legacy Ctrl-Shift-Enter)24concentrated in Capacity

4.2 Sheets

SheetPurposeUsed rowsStatus
DashboardDaily plan view, KPI cells, refresh buttonActive
OrdersLive order book (imported + manual edits)≈180Active — mixed manual/imported data, no input validation
OrderArchive_2019 / _2020_22Frozen order history≈150Dormant — safe to extract
Capacity / MachineList / ShiftsMachine load model (10 machines)≈60Active — 24 legacy array formulas
BOM_Lookup / Materials / SuppliersCosting reference data≈175Active — clean structure, good candidate for a reference table
PriceBands / JobCostingQuantity bands; per-job cost build-up≈90Active — core logic, verified in §7
DispatchLog / Quality_NCRDispatch records; non-conformance log≈175Active
Holidays / Params / Lookup_RefsCalendars, settings, list sources≈40Active — Params mixes config with hard-coded paths
Scratch, zOld_Rates (hidden)Author's workspace; 2013 rates≈70Dormant — zOld_Rates still referenced by 1 broken name

4.3 VBA modules

Component≈LOCRoleHealth notes
modMain310Orchestration, daily plan buildWorkable; DoEvents loops, screen-update juggling
modImport280CSV order importHard-coded path C:\Users\g.hartley\Desktop\orders_export.csv; pervasive On Error Resume Next
modCosting870Job cost engineLogic sound (12/12 golden cases); style poor — GoTo flow, undeclared variables, magic numbers
modEmail240Dispatch emailsClassic Outlook COM only — incompatible with new Outlook
modArchive190Year-end archivingSheet-copy approach; created the “_FINAL” copy culture
modUtils220Shared helpersUK/US date-parsing bug (CDate on dd/mm strings) — active data-quality risk on import
modPrint150Labels & paperworkPrinter path hard-coded (\\HFL-SRV01\Zebra-Dispatch)
modLegacy_DO_NOT_TOUCH420Dead code (2014 planner)99% unreachable — but one live call remains (see R9)
modAuth90Sheet protectionHard-coded password, reused everywhere; protection ≠ security
Sheet modules ×3380Change-event side effectsHidden coupling: edits trigger recalcs and writes users can't see
ThisWorkbook230Open/close hooksAuto-connects legacy ODBC DSN HFL_JOBS (Access 2010 era)

4.4 External dependencies

DependencyUsed byStatus
C:\Users\g.hartley\Desktop\orders_export.csvmodImportFragile — leaver's profile folder, currently recreated by IT as a workaround
\\HFL-SRV01\shared\rates.xls2 formulas + 1 nameDead — file removed ≈2021; values frozen since
Outlook (COM automation)modEmailFragile — classic Outlook only
ODBC DSN HFL_JOBSThisWorkbookLegacy — Access-era DSN, per-machine setup, undocumented
Printer \\HFL-SRV01\Zebra-DispatchmodPrintFragile — breaks on printer rename
Add-in HFL_Tools.xlam3 formulasMissing — not supplied; 3 cells show #NAME? (confirmed cosmetic only)

5.Risk register

IDRiskSev.Likelihood (12 mo)Impact if it firesMitigation
R1Key-person: sole author retired; no docs, no handoverHIGHAlready realisedAny breakage → external help, days of downtimeThis report + Phase 0 documentation; test harness (§7)
R2Hard-coded personal path in import chainHIGH~60%Order import stops silentlyConfig sheet + UNC path (Phase 0); then managed intake (Phase 1)
R3Outlook COM dispatch emailing vs. new Outlook rolloutHIGH~70% (IT plans migration)Dispatch notifications stop same-dayPhase 1: move to Power Automate / Graph-based flow
R414 broken named ranges; 2 feed costing via error-masked codeMED~40%Silent wrong costsPhase 0: fix or retire all 14; remove On Error Resume Next from costing path
R5No versioning; divergent “_FINAL” copiesMEDAlready realisedTeams working from different numbersSingle master + SharePoint version history (Phase 0)
R6≈1,870 volatile formulas → full recalc on every editMEDCertain (perf, not failure)30–90 s freezes; users disable calc, then forgetReplace OFFSET/INDIRECT with INDEX/structured refs (Phase 0/2)
R7UK/US date parsing bug in modUtils on import edge casesMED~30%, monthly windowWrong due dates on ~1st–12th of month ordersPhase 0 quick fix (explicit format); Phase 1 removes the path entirely
R8Hard-coded protection password, widely known patternLOWAccidental (not malicious) structure editsTreat as tamper-seal only; real permissions live in SharePoint (Phase 1)
R9Dead module still referenced by one live callLOW~15%Runtime error on a rarely-used buttonPhase 0: sever the call, quarantine the module
R10Legacy ODBC DSN auto-connect on openLOW~25%Slow/failed opens on new machinesPhase 0: make connection lazy + documented; retire with Phase 1

Likelihoods are our calibrated estimates given HFL's written answers about its IT environment; they are judgements, not measurements — we state them so you can challenge them.

6.The verdict, reasoned

Why not “Keep”? Keeping means accepting R2 and R3 — two high-severity risks with >50% likelihood that stop order intake or dispatch when they fire, in a workbook nobody in-house can repair (R1). “Keep” was the right answer in 2023. It stopped being the right answer when the author left.

Why not “Stabilize” and stop there? Stabilization (Phase 0) is necessary and we recommend doing it first and regardless. But it cannot fix R3: Outlook COM automation is being deprecated around the workbook, and polishing VBA that drives a disappearing interface is spending money on borrowed time.

Why not “Replace”? Because the costing engine — the only part that would be genuinely expensive and risky to rebuild — is the part that works. It encodes 12 years of shop-floor pricing knowledge (setup times, scrap factors, band logic) that exists nowhere else. A full rebuild would re-derive that knowledge at high cost and high error risk for zero operational gain. Replace remains a future option after the fragile edges are migrated; nothing in this path forecloses it.

Therefore: Partially Migrate. Move the two integration-fragile jobs (intake, dispatch) plus archiving to managed services; contain and document the healthy core in Excel. Smallest intervention that removes all HIGH risks.

7.Testing blueprint (how you'll know it's safe)

Every change in the recommended path is gated by the same discipline — golden outputs and a parallel run. This is what turns a risky migration into a boring one:

  1. Golden outputs (before touching anything). We freeze 12 reference cases — real jobs across the quantity bands and material grades, including the two known edge cases (bank-holiday scheduling; multi-material BOMs). For each: inputs, every intermediate figure, final cost. During this assessment we already ran the 12 cases against the current engine: 12/12 reproduce exactly, which is the evidence behind “the costing core is sound”.
  2. Acceptance per phase. A phase is done when all golden cases match to the cent, the affected job runs end-to-end on a machine the author never touched, and a named HFL user signs off in writing.
  3. Parallel run. Two full weekly cycles old-vs-new for intake and dispatch; discrepancies triaged in writing within 24 h.
  4. Rollback. The old path stays runnable (frozen, clearly labelled) for 60 days after cut-over.

8.Effort and cost estimate

PhaseContentEffortElapsedRisk removed
0 — StabilizeFix/retire 14 broken names; extract paths to config; single master + versioning; sever dead-code call; date-bug quick fix; unmask errors in costing path; 1-page runbook15–20 h1–2 weeksR2 (interim), R4, R5, R7 (interim), R9
1 — Migrate intake & dispatchOrder intake to a managed flow (SharePoint list + scheduled import); dispatch mail via supported API flow; archiving becomes a by-product; decommission ODBC autoconnect40–60 h4–6 weeksR2, R3, R7, R10
2 — Contain costingRefactor modCosting for readability (no logic changes, golden-gated); replace volatile lookups; document the pricing model10–15 h1–2 weeksR6, halves R1

Ranges are ±30% (confidence 75% that actuals land inside). Assumes: written access to one HFL power user; no scope growth; HFL's Microsoft 365 tenant available for Phase 1. Prices for fixed-scope execution are quoted separately and only if you ask — this report is complete without buying anything else from us.

9.Next steps

  1. One round of written Q&A on this report is included — send questions any time within 30 days.
  2. If you proceed with Phase 0 (with us or anyone else), start with the named-range repair and the master-copy consolidation: cheapest, highest-yield, zero-risk.
  3. Before any IT rollout of new Outlook, re-read R3 — that is your hard deadline.

A.Appendix — method notes

Inventory produced programmatically (sheet/formula/name/reference walk + VBA parse), then reviewed by hand; numbers in §4 are exact counts on the anonymised copy, not estimates. Verdict scale: Keep (leave as is, monitor) · Stabilize (fix in place, no architecture change) · Partially Migrate (move fragile jobs out, contain the core) · Replace (rebuild). We have no stake in the verdict: we do not sell licenses, and follow-up work happens only at your written request. Confidence percentages express our calibrated judgement — we would rather be checkably wrong than vaguely right.

This is a sample. The real assessment of your workbook costs €790 flat, takes 5–7 business days from file receipt, and starts with a 5-minute written fit check — request it here. If your case isn't a fit, we'll say so within 24 hours.