§12 · Modernisation considerations — Sample audit

12.1 Four tiers

The audit organises modernisation options around four tiers of intervention. They are not ordered as steps; they are alternative scopes appropriate to different findings.

Patch — fix a specific finding in place. Days to a small number of weeks. No architectural change. Risk: low.
Mend — repair a specific function or process while leaving the surrounding system intact. Weeks to a small number of months. Localised architectural change. Risk: low to moderate.
Retrofit — replace a layer or major component (e.g. the integration broker, the reporting layer) while keeping the rest. Months to a small number of quarters. Substantial architectural change in scope. Risk: moderate.
Restructure — replace the system. Quarters to multiple years. Total architectural change. Risk: high.

12.2 What does not belong in each tier

The tier-naming above is misused as often as it is used well. Counter-examples:

“Patch” does not mean “we’ll just do it quickly without a plan.” A patch is small in scope; it is not small in care.
“Mend” does not mean “rewrite this module.” If the work touches the system’s contract with other modules, it is at least a Retrofit.
“Retrofit” does not mean “rebuild on a new stack.” If the replaced layer is a true layer with a stable contract on its boundary, the work fits. If the work cascades into the layer above or below, it has become Restructure.
“Restructure” is not “this is the right thing to do because the current system is old.” Age is not a reason; concrete observed risk that no smaller intervention can address is.

12.3 Mapping the risk register to tiers

Cross-referencing §11:

Patch-tier candidates (~10 person-days each, or less):

R-03 (disable legacy SQL login)
R-04 (DR test + broker key escrow — two patches bundled)
R-06 (narrow svc_broker permissions from db_owner)
R-10 (remove operator-edit of delivery_date via production form)
R-16 (enable TLS on internal SQL traffic)
R-17 (apply SQL Server CUs)
R-18 (drop dormant 2018 schema copy)
R-21 (configure OneDrive backup retention on sales workbook)
R-23 (rehearse tail-of-log restore)

The patch tier is approximately 40–60 person-days of total work, addressing 9 of the 23 register items. Done in a planned campaign over 2–3 months, this materially improves the system’s safety posture with no architectural risk.

Mend-tier candidates (~30–80 person-days each):

R-01 (MRP rollback rehearsal + supplementary recovery tooling)
R-05 (introduce structured no-PO-invoice approval path)
R-14 (extend audit-log coverage)
R-15 (introduce MFA at MES-Plus access layer)
R-19 (SLA monitoring and pre-emptive alerting on EDI partner #1)
R-20 (engineering BOM backlog — process change rather than system change)

The mend tier addresses operational and process risks where the structural shape of the system is acceptable. Approximately 200–400 person-days total, sequenced across 6–12 months.

Retrofit-tier candidates (~120–300 person-days each):

R-02 + R-07 (broker rewrite). The most consequential single Retrofit. Replaces the .NET Framework 4.7 broker with a modern equivalent (most likely .NET 8 or a Python/Go service), restructures secret management (external KMS-backed), and produces durable documentation as a deliverable. Mitigates the 2027 retirement.
R-11 (MRP regenerative-behaviour reform). Modify the MRP to preserve in-flight planner overrides across regenerative recomputes. Requires database change and likely a vendor conversation.
R-12 + R-13 (Crystal Reports replacement). Replace ~40 high-use reports with a modern reporting layer that does not depend on the Crystal runtime. Leave the remaining 140 reports as-is (or as candidates for removal). Power BI extension is the natural fit given the customer already operates a Power BI tenant.

The retrofit tier is substantial work — not optional, but not urgent in the same way the patches are. Total ~500–900 person-days, sequenced across 12–24 months, ideally not all at once.

Restructure candidates — what would justify replacing MES-Plus entirely?

The audit’s view: nothing observed in the current state justifies a Restructure on its own. A Restructure becomes justified if two or more of the following occur:

The vendor announces end-of-life for the MES-Plus product line.
A regulatory change requires a fundamental rework that the vendor cannot or will not deliver.
The business undergoes a transformation that the system’s category cannot serve (e.g. acquisition of a multi-site business; pivot to e-commerce direct fulfilment).
The Retrofit work-list becomes large enough that “replace it” is genuinely cheaper than “rebuild it piece by piece.”

None of these is true today. A Restructure today would be a €450k–€1.2M project taking 18–36 months and would be the highest-risk option available. The audit does not recommend it.

12.4 Sequencing recommendation

A reasonable 24-month roadmap, if the customer chooses to act:

Months 1–3 — Patch campaign. The 9 patch items. ~50 person-days, executed by the customer’s own IT plus 1–2 external days for the DR test and the SQL login audit. Deliverable: a measurably safer system.

Months 2–6 — Broker documentation campaign (R-02 mitigation in advance of full Retrofit). Pair the broker maintainer with an external engineer to extract knowledge. Deliverable: documented broker, runnable demo environment, recorded walkthrough. This is the single highest-leverage activity in the roadmap.

Months 4–9 — Mend campaign. The 6 mend items, sequenced according to business priority. MFA (R-15) and structured no-PO approval (R-05) are the two most operationally consequential.

Months 8–18 — Broker Retrofit (R-02 + R-07). Builds on the documentation campaign. Replace the .NET 4.7 broker with a modern equivalent and external secret management.

Months 12–24 — Reporting Retrofit (R-12 + R-13). Replace the high-use Crystal Reports with a Power BI-based equivalent; retire the dormant ~140 reports.

Months 18–24 — MRP Retrofit (R-11), if still warranted. By this point the planner has worked around the regenerative behaviour for several quarters; the case for fixing it should be revisited rather than assumed.

12.5 What this section deliberately does not do

It does not recommend a vendor or a product. Specific product choices (Power BI vs an alternative; .NET 8 vs Python for the broker rewrite) are downstream of a decision to act. The audit’s role is to make the decision space visible.
It does not quantify ROI. ROI calculations require the customer’s own cost-of-incident estimates and capital-allocation framework. The audit reports cost-of-action; the customer’s leadership composes cost-of-inaction.
It does not assume the customer will engage the audit’s authors for the follow-on work. §2.7 spells out the independence and disclosure stance. The modernisation considerations are written to be useful regardless of who delivers the work.

12.6 Two recommendations the audit will make plainly

Most of this section is option-shaped. Two findings are recommendation-shaped:

Do the DR test (R-04) within the next quarter. Of every finding in the register, this is the one most likely to convert a recoverable scenario into an unrecoverable one if neglected. It is also the cheapest fix.
Start the broker documentation campaign (R-02 mitigation) this calendar year. The maintainer’s retirement date is fixed; the documentation effort scales with the maintainer’s remaining availability. Each quarter of delay materially reduces the quality of the extraction.

The other ~20 findings are matters of judgement and prioritisation appropriate to the customer’s own context. These two are not.