The Old SIEM Still Runs Because Nobody Signed Off the Last Few Use Cases

The first ninety percent moved because somebody wanted it moved

Migrations close quickly at the start. The use cases with an engaged owner go first, because that owner turns up, answers the question about which fields matter, and confirms the output looks right. Then the burndown flattens a few weeks short of done and stays flat.

What is left are the items whose owner was the thing that moved all the others. One belongs to a team that has not replied to three emails. One waits on a log source sitting in another team's change queue, behind work that has a date on it. One has no owner anybody can find, because the person who built it left two years ago. On the program report all three appear as the same open line.

Both platforms keep running through it, and each does exactly what it has been configured to do. Dual running is an ordinary state in a migration of this size, and for a period it is the right state, because the alternative is switching off something a team still relies on. It turns into a problem on the day it stops having an end date.

The program machinery keeps meeting in the meantime. A chase email goes out, the date on the plan gets revised, the item reappears at the next review unchanged. That machinery tracks tasks, and each of these waits on a decision, which has a different owner.

If dual running has no end date on it, the second license is no longer a migration cost. It is an operating cost nobody chose.

What is holding each remaining item

Sign-off mechanics, decision ownership, retained data and use case retirement in a migration tail are CWS positions. Retiring a use case as a legitimate outcome is the part most likely to be argued with, and it is argued for below.

Sorting the tail by what is holding it produces a much shorter list than the item count suggests. The six categories below are the considered version of that list, drawn from three Cortex XSIAM deployments CWS has taken through post-deployment work and from what a wind-down has to settle before the old contract lapses. Treat it as a register to argue with and add to.

The engineering left is uneven. Some items are an afternoon for an engineer who has already done the other ninety percent. Others are the sources that got left until last for a reason: an in-house application whose log format needs a parser written for it, an appliance that has run untouched since it was installed, a feed whose owner left. What holds every one of them, easy or hard, is that a person has to put their name against a change in what the organization has.

• The unresponsive owner. Sign-off is a favor asked of a team with its own priorities and no deadline attached. Silence is the cheapest available answer and it costs them nothing.
• The dependency. The use case cannot be accepted until a source lands, and that source sits in another team's change queue. The migration has no claim on that queue.
• The item with no owner. It was built for a person or a purpose that has moved on. Nobody will approve it because nobody will admit to needing it, and nobody will switch it off in case somebody does.
• The item whose output reads differently. The two platforms group and count in their own ways, so the report arrives in a different shape. Accepting it means accepting a figure that will look unlike last quarter's, and that belongs to whoever presents the pack.
• The item held for an audit. Somebody believes an auditor requires it, the belief has outlived whoever formed it, and removing a control before an audit is a position that needs a volunteer.
• The retained data. Years of logs sit in the old platform under a retention obligation that outlasts every use case on the register. The license is what keeps that history queryable, so it renews by default until somebody decides where the history goes.

Name the decision, then name who can make it

The move that closes a tail is to stop tracking items and start tracking decisions. Take the register, and against every open line write one sentence describing what a named person is being asked to accept. Then write the name beside it. The sentences are uncomfortable to compose, which is how you know you have found the blocker.

The level matters as much as the name. A decision to lose a report belongs to whoever presents that report, and an engineer cannot take it on their behalf. A decision to run without coverage for a defined period belongs to the person who answers for coverage. Push each line to the level that can carry it and the register stops being a chase list.

• Changed output. A named business owner accepts in writing that the report now reads differently, and does it before the first month it lands on their desk.
• Dependency. The security leader accepts that this use case stays where it is until a specific date, and that date joins the migration's critical path. If the source slips, the decommission slips in public.
• Unresponsive team. A stated notice period, sent early enough that objecting is still easy, with a named escalation at the end of it. When the notice expires the decision moves up to a leader who can accept the change on the record on that team's behalf, and their name goes on the register like every other.
• No owner. Somebody senior enough to be wrong about it decides whether the organization still needs the use case. That is a risk acceptance with a name on it, and it is a smaller act than the silence it replaces.
• Audit hold. Read the control, ask the auditor, record the answer with a date. A control names something specific, and the use case that grew up around it covers more ground than the control text asks for.
• Retained data. Somebody states the retention period the old logs actually carry, and somebody owns the route that satisfies it: export to an archive, ingest the history into the new platform, or a rehydration path with a restore that has been tested. Cost, owner and date, and the date sits in front of the contract end.

Every item in the tail is waiting on a person to accept something. A status report cannot do that for them.

Retiring a use case is a legitimate outcome

Put retirement on the register as an outcome with the same standing as migration. Everything on the list arrived carrying an implied instruction to migrate it, and that instruction came from the shape of the program. A use case built four years ago for a system since decommissioned earns its rebuild on its merits today.

The test is short, and it is offered as a considered view: would you commission this now, from a blank page, knowing what the estate looks like. Where the answer is no, migrating it buys an artifact the organization would decline to order, and a maintenance obligation that lasts as long as the platform does.

Retirement is a decision like the others and it wants the same handling. A name, a date, and a written record of the reasoning. The record is what makes it safe.

• Who asked for it originally, and whether that requirement still exists in the form it was written down.
• What disappears if it goes. Some use cases produce output nobody reads and some quietly feed a report three levels up.
• What would have to happen for someone to want it back, and roughly what rebuilding it would involve. A use case that takes an afternoon to rebuild is easy to let go.
• The date and the person. A retirement recorded as a decision protects everyone involved, and that record is the whole difference between retiring a use case and losing one.

The decommission date is the thing being managed

A tail closes against a date, and the date works best when it belongs to somebody outside the security program. A contract end, an infrastructure team waiting on the hardware, a hosting decision already scheduled. Each is external and hard to move quietly, which is the property you are borrowing.

Then work backward. Every line in the register gets a decision date sitting well before the decommission date, and the register goes to whoever chairs the program with names attached. That changes the conversation in the room. A list of open tasks invites a status update, and a list of pending decisions with names against them invites the named people to answer.

Retention is the item most likely to move that date. Years of logs sit in the old platform under an obligation that outlasts every use case on the register, and the license is what keeps them queryable. Settle where the history goes while the contract still runs: export it to an archive, ingest it into the new platform, or keep a rehydration path somebody has actually restored from. Each route has a cost, an owner and a date, and the date belongs on the critical path beside the decommission itself.

Both platforms keep doing what they were configured to do, for as long as they are paid for. The tail stays open because a set of decisions about what the organization still needs has no owner, and those decisions live on your side of the migration.

Written out as sentences, the decisions are smaller than the months of dual running behind them. Some of them say the organization no longer needs the use case, which closes the line as well as migrating it would. All of them stay open until a person signs one, which is why the tail has not moved in months.

A date the program owns is a date the program can move. Borrow one from somebody else.