Triaging the Sprawl: Keep, Merge, Retire

"We'll decide about that one later." Write that next to a register row and you have planted next year's sprawl. A complete sprawl register is a map, not a plan. It tells you the estate has seventeen endpoints and forty-odd flows. It does not tell you which to keep, which to fold together, and which to switch off. That decision is triage, and it is where a consolidation program earns its result. The register's value is entirely latent until every row carries a verdict, an owner, and a reason a skeptic would accept. Skip the triage and you get the most common consolidation failure. A team migrates the obvious servers, loses nerve on the ambiguous ones, and leaves an estate that is smaller but no more knowable. Smaller is not the goal. Known is the goal.

This article is the triage method: a rubric that sorts every register row into keep, merge, or retire. It uses three axes of evidence (usage, ownership, and risk). A worked example follows, assigning verdicts to a realistic register. This is the third article in our Sprawl Consolidation series. It depends on the register built in the discovery sweep. Its output feeds forward: the keep-and-merge verdicts define what the target platform must absorb. The whole verdict set becomes the wave plan that execution works through.

The Three Verdicts

Every endpoint and every flow resolves to exactly one of three verdicts. The discipline of forcing a single verdict per row is deliberate — "we'll decide later" is how the ambiguous rows survive to sprawl again:

• Keep. This endpoint or flow stays roughly as it is, because it is already the right home. It is well run, correctly placed, and probably a consolidation target rather than a source. Most estates have very few genuine keeps; the official server is usually one of them.
• Merge. The work is real and must continue, but not here. The flow moves onto a consolidated platform and the endpoint that hosted it is retired once empty. Merge is the verdict that does the actual consolidating, and most live flows land on it.
• Retire. The endpoint or flow stops entirely, with no replacement, because the work it did is dead, duplicated, or no longer wanted. Retire is the cheapest and most satisfying verdict — every retired row is one you never have to migrate, secure, or audit again.

A fourth outcome, contain, applies to the narrow case of a device or system that genuinely cannot move and cannot be switched off. Examples are the firmware scanner that only speaks one protocol, the appliance no one may touch. Containment is really a constrained keep: the flow stays where it is but gets wrapped in isolation and monitoring. It is rare enough that we fold it into the keep branch here and treat its mechanics under execution. The retiring-plain-ftp series covers the device-containment pattern in depth for the protocol case. The same isolation logic applies to a stubborn endpoint in a consolidation. Every estate has one device that predates the concept of an upgrade.

The Three Axes of Evidence

Verdicts come from evidence, not instinct. Three axes decide almost every row, and the register you built already holds most of the data for them. Instinct is what got the estate to seventeen.

Axis 1: Usage evidence — is it actually alive?

The first question for any row is whether the work is still happening. This is where the register's last activity field earns its place, and where good logging pays off spectacularly. A flow's real rhythm is written in the receiving server's session logs, not in anyone's memory. Compare last-activity evidence against the flow's stated schedule and you get four cases:

• Recently and regularly active matching its schedule: alive. It will be kept or merged, never retired without more thought.
• No activity in two or more full schedule cycles: presumed dead — a retire candidate, but announce before you act, because "dormant" occasionally means "annual."
• Active but not matching any known flow: a discovery you missed, or an intruder. Resolve it before triaging it.
• Cannot tell because the endpoint keeps no usable logs: a finding in itself. An endpoint that cannot evidence its own use is a strong merge-or-retire candidate on that basis alone. You should not be running infrastructure you cannot observe.

Where logs are thin, buy yourself evidence before deciding: turn on or turn up logging and watch for a full cycle. This is the phase where a consolidated platform's activity logging quietly changes the game. Flows move onto a server such as Sysax Multi Server, which records every session to file and database. Once they do, the usage evidence for the next review is already accumulating. So the triage you do now is the last one you run blind. The general principle — that you cannot review what you did not log — is the subject of our what to log article. Read it before you conclude a quiet endpoint is dead. Quiet is not dead. Quiet is sometimes annual.

Kestrel Payroll found that out with a week to spare. Their triage marked an SFTP endpoint as retire after two silent quarters. The shutdown notice went out with a date on it. Three days before the date a reply arrived from the benefits team. That endpoint received the pension statements file once a year, in the first week of January. It had done so without incident for as long as anyone could remember. The verdict became merge and the flow gained an owner and a register row. The shutdown date was moved to the week after the file had landed on the new platform. Nothing broke, because the notice had gone out before the switch was thrown. The lesson Kestrel kept was to compare silence against the flow's own cycle rather than the calendar. It was also to treat the announcement as part of the evidence, not a courtesy.

Axis 2: Owner status — is anyone accountable?

The second axis is human. Every row's owner field falls into one of three states, and the state changes the verdict. How to fill that field and keep it filled is the subject of flow ownership and contacts:

• Clear owner who confirms the flow matters. The easy case: the verdict is keep or merge, and the owner is your partner in executing it.
• Clear owner who cannot justify the flow. Also easy, and quietly common — the owner says "honestly, I don't think anyone uses that any more." That is a retire, with the owner's sign-off as your evidence.
• No owner at all. The dangerous case. An unowned endpoint is the estate's highest risk: no one patches it, reviews its accounts, or notices when it misbehaves. Unowned rows get priority. One triage move is to find an owner willing to claim it — which usually converts it to merge. The alternative, failing real effort, is to retire it under a documented "no owner found" decision.

Ownership interacts with usage in a way worth naming: the truly frightening row is active but unowned. That is a server moving files nightly that no human will claim. That combination is both a security finding and an operational trap. It should be escalated, not quietly migrated, because until someone owns it you cannot safely change it. It is not a mystery. It is a liability with a schedule.

Axis 3: Risk — what does this row expose?

The third axis ranks urgency once usage and ownership have set direction. Score each row on the exposure it carries. Does it move sensitive data, sit reachable from outside, run unpatched software, use cleartext protocols, or hold credentials that outlive their purpose? Every live endpoint is attack surface — the point our transfer attack surface article develops. The register's protocol, exposure, and credential fields feed the score directly. Risk rarely changes the verdict (a high-risk live flow is still a merge, not a retire), but it sets the order. High-risk rows move first within their verdict, because every day they persist is a day of avoidable exposure. A high-risk retire — an unowned cleartext endpoint reachable from the internet — is the single most valuable thing you can do early. It removes exposure at zero migration cost.

A practical scoring shortcut keeps this axis from becoming an essay per row. Rate each of five factors as high, medium, or low: data sensitivity, network exposure, protocol security, patch currency, and credential hygiene. Let the worst single factor set the row's band. A row that is low on four factors and high on one (an internet-reachable listener, say) is a high-risk row. An attacker only needs the one open door. This "worst-factor-wins" rule matches how exposure actually works and stops a spreadsheet of averages from lulling you into treating a genuinely dangerous endpoint as medium. Record the driving factor alongside the band, because "high — because cleartext and internet-facing" is an argument, while "high" alone is just a color.

The Decision Flow

The three axes combine into a repeatable decision procedure. Run every register row through it and you get a verdict you can defend in a change-advisory meeting:

A Worked Triage

Abstractions decide nothing; verdicts do. Here is the composite estate from earlier in the series, run through the rubric. Each row shows the evidence on the three axes and the verdict it produces. This is exactly the artifact your triage should generate, one row at a time, with a human able to defend every verdict aloud:

Read the verdict column and the strategy becomes visible. One keep — the server that becomes the target. Five merges — the real consolidation work, each folding a scattered flow onto that target. One retire — free, once Finance confirms it. One contain — the appliance that will never change. That distribution is typical: consolidation is mostly merging, punctuated by a few satisfying retires and a rare stubborn contain. Notice too how the two unowned rows (ftp-legacy-03 and sftp-tmp-02) both carry "assign owner first" or "escalate." You cannot merge or retire safely until someone can tell you what breaks.

Turning Verdicts Into a Work List

The triaged register is nearly a plan, but two more moves make it actionable. First, group the merges by target tenant: the flows that will live together on the consolidated platform — by owning department, by partner, or by sensitivity. That grouping is exactly the folder taxonomy the target design must provide. Engineering's flows become Engineering's tenant area; the partner flows become per-partner areas. This is the same directory-tree thinking our designing directory trees article develops, applied at the estate level.

Second, rank within each verdict by risk, so the wave plan front-loads exposure reduction. The high-risk retires go first (free wins that remove attack surface). Then come the high-risk merges (exposure that costs migration effort but must not wait), then the routine merges, then the low-risk cleanup. The contain items run on their own track, because they are a design-and-approve project rather than a migration. The result is an ordered list where the top rows deliver the most risk reduction per unit of effort. That is precisely the argument that keeps a consolidation funded through its dull middle. Every program has a dull middle; that is where funding wanders off.

Add one field to each register row to capture the verdict defensibly. This is the triage record the change-advisory board and the auditor will both ask to see:

TRIAGE RECORD — append to each register row

Verdict:        keep / merge / retire / contain
Usage evidence: last-activity date + source (e.g. "server log")
Owner state:    confirmed-matters / confirmed-dead / none-found
Risk band:      high / medium / low
Risk driver:    the one factor that set the band
Merge target:   tenant / area on the consolidated platform (if merge)
Signed off by:  named human who accepts this verdict
Decided on:     date
Wave:           assigned execution wave (filled at planning)

Handling the Genuinely Ambiguous

Most rows triage cleanly. A stubborn few resist, and they deserve a named tactic rather than the "decide later" pile that reconstitutes sprawl:

• Alive but purpose unknown. Do not retire on ignorance. Instrument it: heighten logging and watch a full cycle. If it truly never fires, announce a shutdown date and retire on silence. If it does fire, the log tells you who to ask.
• Owned but the owner is leaving. Reassign ownership before the person goes — an orphaned-in-advance flow is tomorrow's unowned row. This is exactly the transition our scheduled job hygiene guidance is built to prevent.
• Duplicate of another flow. Two teams doing the same transfer separately is a merge-into-one, not two keeps. But confirm the outputs really are equivalent before collapsing them, because "nearly the same" flows sometimes hide a real difference.
• Cheap to keep, awkward to move. Resist the false economy. A flow left in place "because moving it is annoying" is a future sprawl seed. If it is worth running, it is worth running on the target. The awkwardness usually lives in a brittle homegrown script. Re-platforming it onto a scheduler built for transfers — Sysax FTP Automation, for instance, with its wizard tasks, scheduling, and retry — is often less work than the migration you were dreading. Only genuine contain cases stay put.

What Triage Hands Forward

When the last row carries a verdict, an owner, and a risk rank, you hold the two artifacts the rest of the program runs on. The keep-and-merge set is the requirements document for the target platform. It says how many tenants, which protocols, what sensitivity mix, and how much capacity the consolidated server must carry. Those are the inputs the next article turns into a design. The risk-ranked verdict list is the backbone of the wave plan, ordering the moves so exposure falls fastest.

Name what you have avoided, because it is the quiet half of the result. The organizations that triage properly do not have the awkward conversation, two years on, about the server nobody remembers deciding to keep. (I have sat in that conversation, and nobody enjoys it.) That is because every keep, merge, and retire in your estate now traces to a documented reason and a named human. That traceability is not bureaucracy; it is the difference between a consolidation that holds and one that quietly regrows. Next, the target: designing the platform that all those merges will land on.

Frequently Asked Questions