How I assess an inherited data platform before planning its modernisation

If you are taking responsibility for a data platform you did not build, start by tracing how data reaches a business decision. I map that path with the people who operate it, assess the risks against evidence, and only then sequence the modernisation. The assessment should leave the team with findings they can act on and a roadmap that explains which dependencies determine the order.

I start at the consuming end. Which report or application would somebody miss if it stopped working? Who uses it, and what would they do with stale data? From there I trace the flow back through transformation to the source, checking the running system against the documentation.

I ask an engineer to walk me through a recent change along that path, including how they knew it had reached production. That gives me something to compare with the architecture diagram. I record gaps as questions with a person who can resolve them; an undocumented dependency stays marked as uncertain until somebody checks it.

The platform discovery checklist helps structure those conversations. I keep the resulting map small enough that the team can correct it during a review, with links to the repositories that support each connection.

For strategy, I ask which business commitments depend on the platform and where planned work concentrates delivery risk. A replacement already in progress needs a credible handover condition. I want to see who will accept the new path and what happens to work still using the old one.

For architecture, I follow failure through the same data flow. Can the team tell that an upstream step failed before someone uses its output? Can a failed run be repeated safely? I attach the observed behaviour to the finding so the proposed fix has a verifiable endpoint.

For developer experience, I follow a change from a local checkout through review and deployment. I record waiting points and missing instructions. The enterprise product operating model is useful when the delay depends on decision rights or ownership beyond the engineering team.

I rank a finding by the consequence of leaving it open. The effort to fix it goes in a separate field. Otherwise a large architectural improvement can push a small correction out of sight even when that correction protects data people use today.

Idempotency is a useful check: repeating a run should not introduce duplicate effects. Observability is another: the team needs to see whether the data arrived and whether downstream output is fit to use. Where a local fix can address either gap, I put it ahead of work that depends on replacing the orchestrator. If the existing runtime prevents a reliable fix, I record that dependency and move the enabling work forward.

I use this checklist to collect evidence. An unchecked item becomes an open question with an owner, rather than a failed score.

• Name the business decision supported by a live report or application and its accountable owner.
• Trace its data flow back to the source and link the relevant repositories.
• Compare the running path with the documentation and mark uncertain connections.
• Walk through a recent production change with the engineer who shipped it.
• Check what happens when an upstream step fails or finishes late.
• Establish whether repeating a failed run changes the resulting data.
• Identify who receives failure signals and how they decide whether output is usable.
• Record delivery dependencies in the current roadmap, including work already being replaced.
• Give each finding an evidence link and an owner who can verify the proposed fix.
• Review the severity ranking with the team and write down the modernisation dependencies.

I use the following rubric across the assessment. The example row is hypothetical and describes no client system.

Severity	What qualifies	What it triggers
Critical	An active failure is harming current operations and needs containment.	Move into incident handling with an accountable lead; keep the roadmap discussion separate.
High	Evidence shows a credible path to material disruption, with no dependable recovery or detection.	Assign remediation ahead of dependent modernisation work and agree how the fix will be verified.
Moderate	A demonstrated delivery or reliability gap has a workable interim measure.	Schedule the fix with an owner and document when the interim measure stops being acceptable.
Low	A local maintainability gap has no demonstrated operational consequence yet.	Keep it in the owned backlog and revisit if evidence changes.
Hypothetical example: High	A failure alert has no recipient, so a failed refresh could remain unnoticed.	Assign the alert recipient and verify the response path before expanding the workload.

An active incident needs containment before a broad assessment. A platform that has not served a real workload needs discovery around its intended users; there is no live operating path to inspect yet.

Limited access also limits the conclusion. If I cannot inspect a relevant layer or speak to its operator, I mark the finding as unverified and name the missing evidence. The assessment then carries an explicit boundary around that layer.

I offer a platform audit or roadmap reset through Advisory & Sprints. You receive the assessment with its evidence boundaries, ranked findings, and a modernisation sequence your team can use to plan the work. We agree the platform boundary and the decisions the review needs to support before it starts.

My Bahlsen case study describes the engagement behind this field note.