Hypercare and Production Support Interviews: A Masterclass

What it is

Hypercare is the deliberately abnormal period of elevated support that surrounds a go-live. Something new has been put in front of real users and real money: a new ERP, a replatformed order path, a migrated payments stack, a merged tenant, a first release into a new market. For a defined window afterwards, the organisation runs a support arrangement it has no intention of running forever, because the risk profile immediately after a cutover is nothing like the risk profile of a system that has been in production for two years and whose failure modes are known.

The word gets used loosely, which is part of why it is a good interview subject. Some organisations mean "the implementation team keeps their phones on for a fortnight". Some mean a formally chartered service with its own governance, its own severity matrix, its own reporting line into a steering committee, and a signed exit gate. The gap between those two readings is where most hypercare failures live, and an interviewer asking about it is usually trying to find out which one you have lived through.

What makes hypercare distinct from business-as-usual support is not that people work harder. It is that four things are simultaneously true which are not true in steady state. The system's behaviour under real production load and real production data has never been observed, so your entire model of what normal looks like is a projection rather than a measurement. The people who built it are still available, so the escalation path can reach the person who wrote the code, which will not be true in three months. The business has not yet adapted its own processes to the new system, so a large fraction of the incoming volume is not defects at all. And the decision to go back is still on the table, but it is decaying: every hour of production data written into the new system makes reversal more expensive, and at some point it becomes impossible.

That last property is the one that gives hypercare its particular pressure. Ordinary production support is a steady-state activity with no deadline. Hypercare runs against a clock that nobody controls, in which the option value of the rollback plan is draining away while the information needed to decide whether to use it is still arriving.

The arc from cutover to steady state

Almost every hypercare engagement, whatever the domain, follows the same shape. Learn it as a sequence of decisions rather than as a Gantt chart, because the box names change per organisation and the decisions do not.

flowchart TD
    accDescr: Hypercare as a sequence of decisions from cutover and go-live through elevated monitoring and a war room, the triage classify and fix cycle, and stabilisation as the arrival rate falls, to the exit-criteria branch, where meeting them hands over into the support model and failing them extends hypercare or invokes rollback and returns to the fix cycle.
    A[Cutover complete and go-live declared] --> B[Elevated monitoring and war room]
    B --> C[Triage classify and fix cycle]
    C --> D[Stabilisation and falling arrival rate]
    D --> E{Exit criteria met}
    E -->|yes| F[Handover into the support model]
    E -->|no| G[Extend hypercare or invoke rollback]
    G --> C

The branch out of the exit gate is where the interesting judgement lives, and it is the part candidates skip. Everything before it is process that a competent programme manager can run from a template. The decision at that diamond is a genuine judgement made with incomplete information under commercial pressure, and whether you can articulate how it is taken, on what evidence, and by whom, is most of what separates a strong answer from a rehearsed one. Note also that the loop back from the extend branch returns to the fix cycle rather than to the war room, which is deliberate: extending hypercare usually means extending the fix capacity and the reporting, not restanding a room that was correctly stood down.

Hypercare against business-as-usual support

It helps to be able to state the difference crisply, because a surprising number of interviews open with exactly that question and the weak answer is "hypercare is more intense".

The rows people underrate are funding and dominant issue type. Funding is why hypercare ends: the project budget closes, and if nobody has arranged for the operational budget to absorb the residual load, the support model inherits a workload it was not sized for and the whole thing degrades quietly. Dominant issue type is why hypercare metrics are so often meaningless, which is a theme this page returns to more than once.

Entry criteria, and why they exist at all

Entry criteria are the conditions under which hypercare is allowed to begin, which sounds like bureaucracy until you have seen the alternative. Without them, hypercare starts by default the moment the cutover finishes, whatever state anything is in, and the first week is spent discovering that the monitoring was never connected, the support team has no access to production, and nobody agreed who can approve an emergency release.

A reasonable set of entry criteria covers readiness on four axes. Technical readiness means the cutover checklist is complete and signed, data migration reconciliation has run and its results are accepted, the rollback plan has been rehearsed rather than merely written, and monitoring and alerting are live and confirmed to be emitting. Operational readiness means the rota is populated with named people who have confirmed availability, access and credentials are provisioned and tested rather than assumed, the incident tooling is configured with the right queues and routing, and the runbooks exist in a place the on-call person can reach at three in the morning. Business readiness means the affected user population has been trained and knows where to raise issues, the super-user or key-user network is identified by name, and any manual workarounds required from day one are documented and staffed. Governance readiness means the severity definitions are agreed and published, the escalation path names individuals rather than roles, the communication cadence and its audience are set, and the exit criteria are written down before the window starts.

That last point is the one interviewers probe hardest. Exit criteria agreed at the start are a contract; exit criteria negotiated at the end are a fight. If nobody wrote them down beforehand, the exit conversation becomes a debate between a delivery team that wants to be released and a business that has discovered it likes having the builders on speed dial, and that debate is decided by whoever is more senior rather than by whether the system is stable.

Exit criteria and how they are evidenced

Exit criteria are only useful if each one can be evidenced from something other than an opinion. The failure pattern is a criterion like "the system is stable", which is unfalsifiable and therefore decided politically.

The right-hand column is not cynicism, it is the material of the interview. Anyone who has run a hypercare exit has watched at least three of those happen, and being able to name them without bitterness is a strong seniority signal. The candidate who describes exit criteria as a clean checklist has read about hypercare; the candidate who describes how the checklist gets gamed and what they did about it has run one.

The war room and when to stand it down

The war room is the physical or virtual space where the cross-functional group sits together during the highest-risk part of the window. Its value is real and specific: it collapses the coordination cost between functions that normally communicate through tickets. When a business user, a functional consultant, a developer, a database administrator and an infrastructure engineer are in the same room, a question that would take two days of ticket ping-pong takes ninety seconds. That is worth an enormous amount in the first week, when the dominant cost is not fixing things but working out what is wrong.

Its cost is equally real and much less discussed. A war room consumes the entire attention of the most expensive people in the programme. It creates a channel that bypasses the ticketing system, so the record of what happened lives in people's heads and in a chat transcript nobody will read. It trains the business to escalate directly rather than through the process the support model will depend on. And it has enormous inertia: nobody wants to be the person who stood down the war room the day before the incident that needed it.

So the discipline is to stand it down on a schedule agreed in advance, tapering rather than stopping. Typically that means all-day presence for the first days, then a fixed daily stand-up plus an on-call arrangement, then the stand-up moves to a shorter check-in, then it becomes the normal service review. Each taper step should have a stated condition and a stated fallback, so that reconvening is a defined action rather than an admission of failure. The condition to state out loud is that the war room ends when tickets start flowing through the process rather than around it, because that is the property the support model actually depends on.

Why we need it

Hypercare exists because the risk of a cutover is concentrated in time in a way that ordinary operations are not, and because the mechanisms that make steady-state support work are all missing at exactly the moment they are most needed.

Consider what a normal support model relies on. It relies on a baseline: an engineer looking at a dashboard knows what Tuesday morning normally looks like, so a deviation is visible. After a go-live there is no baseline, because the system has never been observed with production traffic and production data. Every number on every chart is being seen for the first time, and the question "is this bad" cannot be answered from the chart alone. A queue depth of four thousand might be catastrophic or might be exactly what the batch design intended, and nobody in the room knows which.

It relies on documented procedures. A support analyst resolves a known issue by following a runbook someone wrote after the last time it happened. After a go-live, nothing has happened yet, so no runbook has been written from experience. What exists was written in advance by people imagining failure modes, which is a useful exercise and a poor substitute. The first genuine incident of any class is always handled without a runbook, and hypercare is the period in which most classes occur for the first time.

It relies on the issue mix being dominated by defects and infrastructure. That mix is what a support model is designed and staffed for. Immediately after a go-live, the mix is dominated by things that are not defects: data that migrated in a state the new validation rejects, configuration that was set correctly for the test environment and wrongly for production, and users doing something the way they did it in the old system. A support tier staffed and skilled for defect triage drowns in that mix, and worse, it misclassifies it, which poisons every metric anyone is using to judge whether the go-live succeeded.

It relies on there being time. Steady-state support can afford a two-day investigation because the system worked yesterday and will work tomorrow. In the first week after a cutover, a two-day investigation might be two days in which the business cannot invoice, or two days of corrupt data written into a ledger that will need unpicking. The economics of speed are different, which changes what a correct decision looks like.

And it relies on the decision space being narrow. In steady state your options are fix, mitigate, or accept. During hypercare there is a fourth option that will not be available later, and it dominates the others when it applies: undo the whole thing. Rollback is a live option in a way it never is again, and reasoning about it, timing it, and knowing when it has expired is a category of judgement that only exists in this window.

There is a commercial dimension too, and interviewers at consultancies and systems integrators care about it a great deal. Hypercare is frequently a contractual deliverable with a price and a duration attached. It is the last thing the client experiences before the invoice is settled, and the impression it leaves determines whether the account renews. A hypercare period that runs long is a direct margin loss to the supplier and a direct trust loss with the client. A hypercare period that ends early because the exit was pushed through leaves a support team failing in month two and a client who will say so. Anyone being interviewed for a delivery lead, engagement manager or service transition role is being assessed on whether they understand that hypercare is simultaneously a technical activity and a commercial one, and that the two pull in opposite directions.

Finally, hypercare exists because organisations are bad at transitions and know it. The implementation team and the support team are usually different people, frequently different companies, and occasionally on different continents. Knowledge that lives in the heads of the first group has to end up in the systems and the habits of the second, and there is no mechanism that does this automatically. Hypercare is the scaffolding for that transfer. When it is designed well, the support team is in the war room from day one, taking tickets under supervision and writing the runbooks as they go. When it is designed badly, the support team is introduced in the final week and handed a document pack.

What interviewers ask

Hypercare questions cluster into recognisable rounds, and each round is scored on different observable behaviour. Knowing which one you are in tells you which behaviour to display, and stops you giving a process answer to a judgement question.

The definition and framing round

Someone establishes early whether you have been near a real one. The question is bland, the scoring is not. "Hypercare is enhanced support after go-live" is a sentence from a proposal. What is graded is whether you name the two properties that make it a distinct thing: that it is bounded by criteria at both ends, and that the resolution path runs through the people who built the system rather than through the people who will support it.

The second signal in this round is whether you volunteer the cost. Hypercare is expensive, disruptive to the delivery team, and habit-forming for the business. A candidate who describes it purely as a good thing has not paid for one. A candidate who says "and the risk is that it becomes permanent, because the business prefers it and nobody is incentivised to end it" has.

The gate and criteria round

Asked how hypercare ends, weak answers give a duration. "Four weeks" is not an answer, it is a booking. What is scored is whether your criteria are evidenced, whether you name the signatory, and whether you have thought about the gaming.

The specific probe most interviewers use is to push back: "the business says they are not comfortable, but all your criteria are met". What they are looking for is whether you treat that as a legitimate signal or as an obstacle. The strong answer says the discomfort is data, so you find out what specifically is driving it, because it is usually one unresolved thing rather than a general feeling, and it is frequently something outside the criteria you wrote. Then you either add it as a criterion and fix it, or you exit with an agreed enhanced arrangement for that specific area rather than extending everything. Extending the whole window because of one unresolved concern is the expensive default.

The incident scenario round

You are handed a symptom and a day number and asked to reason aloud. This carries the most signal of any round because the behaviour is hard to fake. Four things are graded.

Whether you stabilise before you diagnose. Under hypercare pressure the instinct to understand first is strong and usually wrong, and it is the same discipline covered in running an incident as first responder and in what to do when a deploy has degraded production. The hypercare-specific twist is that stabilising may mean falling back to the old system or to a manual process, which is an option ordinary incidents do not have.

Whether you bound the impact before you commit to a cause. How many users, which process, is money involved, is data being written that will need repair. Candidates who leap to a probable cause without bounding the blast radius are answering a debugging question rather than an incident question, and the difference is exactly what the round is testing.

Whether you communicate on a cadence rather than on progress. The business during hypercare is watching, and the failure mode is going silent while you work. A candidate who says "I would send an update every thirty minutes even if the update is that we have nothing new" has told the interviewer something specific about having been in the room.

Whether you separate restoring service, fixing the cause, and fixing the class. Three timescales, three owners. Conflating them is the commonest structural weakness in scenario answers across every domain, and it is more visible here because during hypercare the pressure to declare something finished is intense.

The classification round

You are given an incoming issue and asked what it is. This round exists because misclassification is the specific failure that makes hypercare metrics worthless, and interviewers who have been burnt by it test for it deliberately. What is scored is whether you reach for the four-way split rather than the binary of bug or not-a-bug, whether you know what each category routes to, and whether you understand why the classification has to be reviewed rather than trusted at first touch.

The severity and priority round

Asked to define them, or handed a situation where they conflict. The graded signal is whether you hold them apart, whether you can say who owns each, and whether you can describe a case where a low-severity issue is a high priority and the reverse. Candidates who use the two words interchangeably are marked down immediately, and it is one of the fastest discriminators in the whole subject, which is why it comes up so often. The same distinction underpins writing a bug report that gets fixed, and interviewers who have read a lot of poor bug reports ask it for that reason.

The rollback judgement round

Almost guaranteed at senior level. You are asked whether you would go back, usually with deliberately incomplete information. What is scored is whether you know the window is decaying, whether you can name the specific things that close it, whether you have a decision point defined in advance rather than improvised, and whether you understand that rollback is itself a risky operation rather than a safe default.

The tell that marks a candidate as inexperienced here is treating rollback as free. Rolling back after four days of production trading means reversing four days of business transactions, and depending on the domain that may be harder than fixing forward. The candidate who says "we would roll back" without asking what happens to the data written since cutover has not done it.

The handover and transition round

Increasingly its own round, particularly at systems integrators and in service transition roles. The setup is that the support team was not involved in the build, and the question is how knowledge gets from one to the other. Scored on whether you design the transfer into the hypercare window rather than appending it as a document handover at the end, whether you can name the mechanism by which you verify the transfer worked, and whether you have a view on the residual defect backlog and who owns it.

The stakeholder and communication round

Non-technical in form, entirely consequential in effect. An executive wants hourly updates, a client sponsor is threatening escalation, a user community is losing confidence. What is scored is whether you can produce actual wording rather than describe communication in the abstract, and whether your wording commits to facts and next update times rather than to reassurance. Interviewers frequently ask you to draft the update out loud, and the difference between candidates is stark.

The retrospective round

You are asked what changed after the last hypercare you ran. The graded content is whether the review produced anything, and whether you can describe a decision you got wrong. A review that produced a document is a review that produced nothing. A candidate who can name a specific change to the runbook set, the alert thresholds, the severity definitions or the entry criteria, and can say what it cost to make, is describing a real feedback loop.

How the same question is scored at different levels

Candidates commonly answer one level away from the role. At mid level, the bar is correct mechanism: what a severity matrix is, how triage works, what a runbook should contain. At senior level, mechanism is assumed and grading moves to judgement under conflicting pressure: when to stand down the war room, when the exit criteria are being gamed, when to hold the line against an executive. At lead and above it moves again, to designing the arrangement itself: how hypercare is scoped and priced, how it is staffed without destroying the delivery team, how the transition is structured so the support organisation is capable rather than merely appointed. Bringing deeper mechanism to a lead interview is the standard way to be downlevelled here.

Tells that you have not run one

Interviewers who have run hypercare share a short list of things that give candidates away. Describing hypercare as a duration rather than as a set of conditions. Assuming every incoming ticket is a defect. Treating rollback as costless. Proposing a war room without saying how it ends. Never mentioning data quality. Talking about SLAs during hypercare as though the contractual support SLA already applies. Assuming the support team can be handed a document pack. Describing the exit as a date. And, most reliably of all, giving an account of hypercare in which nothing went wrong.

Questions

These are phrased the way interviewers phrase them. The answers are the substance of a strong response rather than scripts to recite.

Framing, scope and governance

What is hypercare, and how is it different from normal production support?

Hypercare is a bounded period of elevated support immediately following a significant change to production, in which the people who built the system resolve issues directly, monitoring is more sensitive than it will be in steady state, and governance runs on a daily rather than a periodic cadence. It begins on defined entry criteria and ends on defined exit criteria, and both of those are the defining features rather than administrative decoration.

The difference from normal support is structural rather than one of effort. Normal support has a measured baseline, documented procedures written from experience, an issue mix dominated by defects, and no live option to reverse the change. Hypercare has none of those. It runs without a baseline, so nobody can tell whether an observed number is a problem. It runs without experience-derived runbooks, so the first instance of every issue class is handled improvised. Its issue mix is dominated by data, configuration and user behaviour rather than defects, which breaks the assumptions a support tier is staffed against. And it runs with a rollback option whose value decays hourly.

Add the cost, because volunteering it is a seniority signal. Hypercare consumes the delivery team at exactly the point they are most tired, it trains the business to escalate directly instead of through the support process, and it is habit-forming: the business enjoys having the builders reachable and has no incentive to give that up. Left ungoverned it does not end, it fades, and the fade leaves the support organisation carrying a load it was never sized for.

Who owns hypercare, and who signs it off?

Ownership and sign-off are different, and the answer that separates candidates is knowing they are held by different people. A single accountable owner runs the window day to day, usually the delivery or programme lead on the supplier side or the service transition manager on the client side, and their job is to run the cadence, hold the criteria, and make the escalation calls. Sign-off belongs to whoever carries the consequence of the system failing after exit, which is the business service owner and, where the system touches money, finance.

That split matters because the two have opposed incentives at the gate. The owner wants to close the window, because the budget is closing and the team is exhausted. The signatory wants to keep it open, because their exposure begins the moment it shuts. A gate with agreed evidence-based criteria converts that tension into a conversation about facts. A gate without them converts it into a conversation about seniority, and seniority wins, which is how hypercare periods end up running for six months or ending three weeks too early depending on who was in the room.

Name the third party too: the support organisation that will inherit the system. They are neither owner nor signatory in most arrangements, and they are the ones who live with the outcome. If they have no voice at the gate, the gate is being decided by two parties who both leave afterwards.

How long should hypercare last?

Reject the framing gently and then give a way to derive it, because the interviewer is checking whether you answer with a number. The duration should be derived from the business cycles the system has to survive rather than from the calendar. If the system participates in a month-end close, hypercare cannot end before a month-end has been completed successfully, because the close exercises code paths and data that daily operation never touches, and it is the single most common source of the first genuinely severe post-go-live incident. If there is a quarterly regulatory submission, a payroll run, a seasonal peak or an annual renewal cycle within reach, the same logic applies with a longer window.

Then add the volume-based condition: the incident arrival rate has to have fallen and stayed down across at least two comparable periods, because one good week after a bad one is noise. And add the capability condition: the support team must have demonstrably resolved issues without escalation, measured rather than asserted.

The practical answer for most enterprise go-lives lands somewhere between two weeks and three months depending on those cycles, but the interviewer wants the derivation, not the range. Offer the range only after the derivation, and only as an illustration.

A phased rollout means you go live five times. How does hypercare work then?

The window becomes a rolling one and the risk profile changes shape rather than disappearing. Each wave gets its own elevated period, but the waves are not equal: the first carries almost all the discovery, and by the third the issue classes are known and the runbooks exist, so what looks like hypercare is closer to a supervised deployment.

Two things need explicit design. First, the exit criteria differ per wave, and pretending otherwise is how a programme exits wave one's hypercare on wave three's evidence. Wave one exits on "we have found and fixed the classes"; later waves exit on "no new classes appeared, and the known ones were handled by support without escalation". Second, and more dangerous, the delivery team is simultaneously supporting live waves and building for the next ones, which is a capacity conflict that will be resolved implicitly in favour of the deadline unless someone resolves it explicitly. Ring-fence the support capacity by name, and expect to defend it weekly.

The genuine advantage of a phased approach is worth stating: it converts one unbounded risk into several bounded ones and gives you real production evidence before the largest population is exposed. The genuine cost is that you run two systems in parallel for longer, with all the reconciliation that implies, and the organisation experiences change fatigue across a much longer period.

Severity, priority and triage

What is the difference between severity and priority, and why does conflating them cause problems?

Severity describes the impact of the issue on the system and its users: how broken it is, how many are affected, whether there is a workaround, whether data or money is at risk. Priority describes the order in which work is done: what gets attention first given everything else in flight, the commercial context, and who is waiting. Severity is a property of the defect. Priority is a property of the queue.

They are owned by different people and derived from different information. Severity is assessed by whoever can see the technical and user impact, typically support or QA, and it should be as objective as the definitions allow. Priority is set by whoever owns the outcome, typically a product owner or business service owner, and it legitimately incorporates things the technical assessment knows nothing about: a regulator visiting on Thursday, a customer whose renewal is being negotiated, a demo to the board.

Conflating them causes fights for a specific structural reason. If there is only one field, then arguing about how bad something is and arguing about when it gets fixed become the same argument, and the person who wants their issue fixed sooner has to claim it is more broken than it is. That is how every ticket in the queue becomes a critical, at which point the field carries no information and triage collapses back to whoever shouts. Two fields let the business get what it wants, which is their issue fixed on Tuesday, without corrupting the record of how bad it was, which is what everyone will need at the exit gate.

The combination interviewers ask about is low severity with high priority: a cosmetic label error on the invoice template, harmless to function, and the invoices go to twelve thousand customers on Friday. Low severity, top of the queue. And the reverse: a severe failure in a batch job used once a year by two people, with the next run four months away. High severity, low priority. A candidate who can produce both examples without prompting has understood the distinction rather than memorised it.

Give me a severity matrix you would use during hypercare.

Present it as an example of a reasonable set rather than as a standard, because these vary considerably by organisation and by domain, and offering one as though it were canonical is a tell.

Two things about this deserve to be said out loud. The word "core" is doing a lot of work and has to be defined per engagement against a named list of business processes, otherwise every team believes their process is core. And the workaround column is the part that gets argued about, because the existence of a workaround is used to downgrade severity when the workaround is a spreadsheet operated by one person who is on leave next week. A workaround only reduces severity if it is documented, staffed and sustainable for the expected duration, and writing that condition into the definition prevents a large fraction of the arguments.

The other thing to add is a rule for aging. An issue that sits at severity 3 for two weeks while the affected team does manual work every day is doing more cumulative damage than a severity 2 that lasted an afternoon. Some organisations handle this by allowing severity to be re-assessed on duration, others by letting priority carry it. Either works; having neither is how the known-error backlog becomes permanent.

Walk me through the first ten minutes of a severity 1 during hypercare.

The ten-minute frame is deliberate: the interviewer wants to know what you do before you understand anything, because that is where the judgement is.

Establish command first. One named person is running it, and they say so explicitly, because the failure mode in the first minutes of a hypercare incident is six competent people all investigating in parallel and none of them coordinating. During hypercare the room is unusually crowded, with the client, the supplier, the infrastructure team and possibly a third-party vendor all present, so the ambiguity about who is in charge is worse than in a normal incident. State the role, state who is doing what, and open one channel that will be the record.

Bound the impact second, in parallel with the first investigation rather than after it. Which business process is affected, how many users, whether transactions are failing or being silently mishandled, and whether data is being written that will need repair. The distinction between failing loudly and failing quietly determines whether you have minutes or hours, and the quiet failure is the one that costs more, which is the same asymmetry discussed in telling a dead monitoring pipeline apart from a healthy system.

Ask the hypercare question third, which does not arise in ordinary incidents: is there a manual or legacy path the business can use right now. If the old system is still available or the process can be run on paper for a few hours, invoking that buys you the time to diagnose properly, and it is very frequently the correct first action even though it feels like a defeat. Knowing that the answer to "how do we stop the bleeding" may be organisational rather than technical is a specific hypercare competence.

Communicate fourth, before you have anything to say. A first notification within ten minutes that states what is affected, what you know, what you are doing and when the next update will come is worth more than a detailed one at the ninety-minute mark, because in the interval the business has been inventing its own account of events and escalating it upwards.

Only then diagnose. And time-box it aloud: "if we do not have a cause in thirty minutes we invoke the fallback" is a decision made while calm, which is the only time it can be made well.

How do you triage a queue that has three hundred tickets in it on day two?

Accept that the queue cannot be triaged item by item in useful time and go structural. The volume on day two is not three hundred distinct problems, it is typically twenty problems reported many times each plus a long tail. So the first move is deduplication and clustering, which needs a human reading titles quickly rather than a process, and it is worth putting your best-informed person on it for an hour rather than distributing it across the team.

Then sort the clusters on two axes rather than one: how many people are blocked, and whether the issue is generating data that will need repair. The second axis is the hypercare-specific one and it is routinely missed. An issue that is merely blocking is costing time and will stop costing the moment it is fixed. An issue that is silently writing wrong data is accruing a repair liability that grows with every hour, and it should jump the queue over things that look more urgent, because the cost of the fix is constant while the cost of the cleanup is not.

Then classify each cluster into defect, data, configuration or training, and route accordingly, because the routing is what actually clears the queue. A large fraction of the three hundred will be training and can be answered by the super-user network rather than by an engineer, and getting that split right on day two is the difference between the delivery team being able to work and the delivery team answering questions.

Finally, publish the clustered view. Three hundred open tickets is a number that frightens an executive; "eighteen distinct issues, of which four are blocking, and here they are" is a number they can govern with. The reframing is honest and it changes the temperature of the programme materially.

Everything coming in is being logged as a critical. How do you fix that?

Diagnose why before you fix it, because there are three causes with different remedies. The definitions may be genuinely ambiguous, in which case people are guessing and defaulting upwards, and the remedy is worked examples: a short list of real tickets with their agreed severity and the reasoning, which is far more effective than a better-worded matrix. The severity field may be being used to buy priority, which is the conflation problem, and the remedy is to introduce or make visible the separate priority field and to demonstrate that using it works, once, publicly. Or the raisers may have learnt that only criticals get looked at, which is a statement about your throughput rather than about their behaviour, and no amount of definition-tightening will fix it.

The third is the one candidates miss and interviewers are listening for. If the queue below critical is not moving, then logging a critical is a rational response to the system in front of them, and the remedy is to visibly clear some non-critical tickets so the incentive changes. Telling people to stop inflating severity while their non-critical tickets sit untouched for a fortnight is asking them to act against their own interest.

Add the governance mechanism: severity is reviewed at triage rather than accepted from the raiser, downgrades are explained to the raiser rather than applied silently, and the reclassification rate is reported. Silent downgrades destroy the trust the process depends on faster than anything else, because the raiser discovers it later and concludes the process is a way of ignoring them.

Classifying what comes in

A ticket arrives saying the total on the report is wrong. Is that a defect?

It might be, and the discipline of not assuming so is the answer. During hypercare an incoming issue falls into one of four categories with completely different owners, fix paths and costs, and the single most damaging thing a hypercare operation does is classify everything as a defect by default.

So for the wrong report total, the four hypotheses are that the calculation is wrong, that the underlying records are wrong because they migrated badly, that a parameter such as a rounding rule or a date range or a company code is set wrongly, or that the report is correct and it differs from the legacy report because the definition changed and nobody told the user. All four present identically to the person raising the ticket, and the fourth is extremely common after a migration, because the legacy report included something the new one excludes by design.

The investigation order that gets there fastest is to reproduce with a single known record before looking at the aggregate, because a wrong total from correct logic over wrong data and a wrong total from wrong logic over correct data are indistinguishable in the aggregate and trivially distinguishable in one row.

Why does misclassifying those categories poison the metrics?

Because every number the programme is being judged on is computed over the classified set, and three separate distortions follow.

The defect count becomes a fiction. If training questions are logged as defects, the defect count reflects how unfamiliar the users are rather than how good the software is, and it stays high long after the software has stabilised. That has direct consequences: the exit gate has a criterion on open defects, so a system that is working fine cannot exit hypercare because the register is full of questions. Conversely, if genuine defects are being closed as user error by a support tier under pressure to keep numbers down, the register understates the risk and the gate passes a system that is not ready.

The trend becomes uninterpretable. The most important signal in hypercare is the shape of the arrival curve, because a falling rate is the evidence that things are converging. But the four classes have completely different natural curves. Training issues spike and decay fast as users learn. Configuration issues appear as new business scenarios are exercised for the first time, so they arrive in bursts tied to the calendar rather than decaying smoothly. Data issues arrive in proportion to how much of the migrated set has been touched, which means they keep coming for months and can accelerate when a rarely-used population is finally processed. Defects decay slowly and unevenly. A combined curve mixes four different processes and tells you nothing about any of them, which is why splitting the trend by class is one of the highest-value things a hypercare operation does with almost no effort.

The remediation is misdirected. If data issues are being counted as defects, the response is more developer capacity, which does nothing, when the correct response is a data quality workstream attacking the source. Every hour of developer time spent writing a correction script for records that will be re-broken by the next interface run is time not spent on the interface. Getting the class right is what points the effort at the generator rather than at the instances.

Add the governance point, because it is what makes this real rather than an observation: classification must be reviewed by someone with both technical and business context, not accepted from the raiser and not decided by a support analyst under volume pressure. A daily reclassification pass over the previous day's tickets takes twenty minutes and changes what the whole programme believes about itself.

How do you tell a data problem from a defect when the symptom is identical?

Reproduce with controlled input. Take a record you construct yourself, correct by definition, and run the same process. If the output is right, the logic works and the problem is upstream in the data. If the output is wrong on clean input, the logic is wrong. That single test resolves most of these cases in minutes and it is remarkable how often it is skipped in favour of reading code.

Then, once you know it is data, ask the question that determines whether you have a problem or a permanent problem: is the bad data static or arriving. A migration defect produced a fixed population which can be identified, corrected and reconciled, and once done it is done. An interface defect is producing bad data continuously, so correcting the existing set without fixing the interface is a treadmill, and the corrections will be quietly undone. That distinction determines whether you write a one-off correction or stop the interface, and getting it wrong is one of the standard hypercare embarrassments: three days of manual correction, then a batch run overwrites all of it.

The related judgement, which interviewers sometimes push into, is whether a test failure of this kind means the software is wrong or the test was, which is the same reasoning as deciding whether a failure is a bug or a bad test applied to production evidence rather than to a suite.

Half the issues turn out to be training. What do you do about it?

Treat it as a signal about the deployment rather than as a complaint about users, and act on volume rather than on individual tickets. Fifty tickets about the same screen is not fifty users being slow, it is one design or one communication failure with fifty reports.

The mechanisms that work are unglamorous. A super-user network, meaning named people embedded in each business area who take the first question and only escalate what they cannot answer, absorbs the overwhelming majority of this volume and absorbs it faster, because the answer comes from someone who knows that team's process. Publish a running list of the top questions with answers where the users actually look, which is usually not the intranet page the project built. Where the same question keeps arriving about one screen, change the screen: a field label, a default, a validation message that explains what it wants. A one-line change to a hint text can retire a hundred tickets, and it is frequently cheaper than answering them.

And feed it back honestly. A very high training volume against a specific area usually means either that the change impact on that area was underestimated, or that the training happened too long before go-live and has been forgotten, or that the process genuinely changed and the training taught the software rather than the new process. Those have different fixes and the difference is worth an hour of analysis.

The point to make in an interview is that this volume is not a nuisance to be filtered out, it is the most direct evidence available about how well the change landed, and a programme that routes it all to the delivery team both wastes the evidence and destroys its own capacity to fix real things.

Observability, and what to watch that you would not normally

What do you monitor during hypercare that you would not monitor in steady state?

Steady-state monitoring is built around known failure modes and a measured baseline, and neither exists yet. So hypercare monitoring has a different job: to detect that something is different, without knowing what normal is.

The largest addition is business-process instrumentation rather than technical instrumentation. In steady state you watch latency, error rates, saturation and queue depths, and those still matter. During hypercare you additionally watch counts of business events against what the business expects: orders created per hour, invoices issued today, payments matched, shipments confirmed, records synchronised to the downstream system. Those numbers have an expectation that comes from the business rather than from a historical series, and they catch the class of failure that is invisible technically. A process that silently stops producing output looks perfectly healthy on every infrastructure dashboard, which is the whole argument in what metrics, logs and traces each answer taken one level up into the business layer.

The second addition is reconciliation as a monitored signal rather than as a periodic report. Counts and control totals compared between the new system and the legacy system, or between the new system and the downstream consumers, run daily and alerted on divergence. During parallel running this is the primary evidence that the cutover worked, and treating it as a monitoring signal rather than as an accounting exercise gets a human looking at it every day instead of at month-end.

The third is the absence signal. Interfaces that should have run and did not, batch jobs that finished suspiciously fast, files that did not arrive, queues that are empty when they should not be. Absence is the failure mode that steady-state alerting is worst at, and hypercare is exactly when new integrations silently fail to fire.

The last two rows are the ones that distinguish an experienced answer. Manual workaround volume is a cost the business absorbs silently and it is the reason a system can look stable while the operations team is doing four hours of manual work every evening. If you do not count it, it never appears in the exit decision, and the exit decision then approves a state nobody would approve if they saw it. Counting it can be crude, a daily number from the team lead, and crude is enough.

Your alerting is producing forty pages a shift. What do you do?

Fix it immediately, because alert fatigue during hypercare is more dangerous than during steady state. In steady state a noisy alert is ignored by people who know the system; during hypercare nobody knows which alerts matter, so the noise consumes real attention and then trains everyone to ignore the channel, and the one that mattered arrives into a room that has stopped looking.

Triage the alerts the way you would triage tickets: cluster, then act on the clusters. Alerts that have fired repeatedly and never corresponded to a real problem get their threshold changed or get removed, with the removal recorded so it is revisited. Alerts that fire on a symptom rather than a condition get replaced by one on the condition, because five alerts from one cause are one alert. Alerts nobody can act on get routed to a dashboard rather than to a person, since an alert with no action is information, not an alert.

The discipline to state is that silencing must be distinguishable from fixing. A silenced alert is a decision that must be recorded with an owner and a review date, because an alert silenced during hypercare and forgotten is a monitoring gap the support team inherits without knowing it exists. Reporting "alerts tuned" at the exit gate while the tuning consisted of muting things is one of the specific ways the gate gets faked, and naming it unprompted marks you as someone who has audited one.

How do you know what normal looks like when the system has never run?

You do not, and the honest strategy is to acquire the baseline deliberately during the window rather than pretending you have one.

Three sources help. The legacy system's history gives you business volumes even though it gives you nothing about technical behaviour: if the old system processed eleven thousand orders on a typical Monday, the new one should too, and a large divergence in either direction is a finding. Performance testing gives you a technical expectation, with the caveat that it was run against synthetic data and a synthetic mix, so it establishes an order of magnitude rather than a threshold. And the business itself holds expectations that were never written down, which is why walking the operations floor and asking "how many of these would you normally do by lunchtime" is a legitimate and underused technique.

Then set alerts wide and tighten them. Starting wide and narrowing as the shape emerges produces fewer false pages than starting tight and loosening, because a false page costs attention you cannot spare while a missed narrow signal in week one is usually caught by the people who are watching everything anyway. Review the thresholds on a schedule, and treat "we now know what Tuesday looks like" as a deliverable of the window rather than a side effect. Handing the support team a set of thresholds derived from three weeks of real observation is a substantial part of what hypercare is for.

Runbooks, on-call and handover

Why are most runbooks wrong by the time they are needed?

Because of when and by whom they were written. A pre-go-live runbook is written by someone imagining a failure, before the system has run, against an environment that is not production, at a point in the project where documentation is the task that gets compressed. Every one of those introduces a specific error.

Imagining the failure means the runbook covers the failures the author could think of, which correlates poorly with the ones that occur. The genuinely disruptive incidents in the first weeks are usually combinations, or they are in the integration between two components each of which has a runbook and the interaction of which has none.

Writing before the system has run means the diagnostic steps have never been executed. The command in step three has a typo, the log path changed in the last deployment, the screenshot is from a build two months old, the URL points at the test environment. None of that is visible until someone follows it at two in the morning, which is the worst possible moment to discover that step three does not work.

Writing against a non-production environment means the runbook assumes access, tooling and data the author had and the on-call person does not. This is the single most common failure: the procedure is correct and the person following it cannot perform it, because the account they have does not have the right, or the jump host requires an approval that takes a day, or the tool is installed on the author's machine. It is the same category as the observation in could you restore production right now that a backup you have not restored is a belief rather than a capability.

And compression means the runbook set is thinner and later than planned, so the ones that exist cover the obvious and the ones that would have covered the awkward cases were never written.

The remedies are all about execution rather than about writing. Every runbook is executed at least once, in production or in a production-equivalent, by someone other than the author, and preferably by the person who will be on call. That single rule removes most of the defects. Runbooks are updated during the window rather than after it, because the person who just resolved the incident is the only one who knows what the real procedure was, and the knowledge decays within days. And the runbook set is treated as a deliverable of hypercare rather than as an input to it: at the exit gate, the meaningful measure is not how many runbooks exist but how many have been executed by the support team.

What should be in a runbook, and what should not?

A runbook is written for a person who is tired, under pressure, and less familiar with the system than the author. That single constraint determines most of the content.

It should state the trigger precisely, meaning the alert or symptom that leads someone here, so that the routing from alert to runbook is unambiguous. It should state the impact and the severity guidance, so the person following it knows how much urgency to apply and whether to wake anyone. It should give the diagnostic steps as executable commands or exact navigation, with the expected output alongside, because "check the queue depth" is useless without "healthy is under two hundred". It should give the remediation steps, and separately state which of them are safe to perform without approval and which are not. It should state the verification, meaning how you know it worked, which is the step most often missing and the reason incidents get closed while still happening. And it should say who to escalate to, by name and with a contact method that works out of hours.

What should not be in it is background. Architecture explanation, history, rationale and design discussion belong in documentation, not in a procedure someone is reading at speed. A runbook that opens with two pages of context will not be read past the first paragraph, and the useful part is buried. Link to the background if it exists; do not inline it.

The other thing that should not be in it is optimism. If a step usually works but sometimes does not, say so, and say what to do when it does not. If the procedure is known to be incomplete for a particular case, say that at the top rather than letting someone discover it halfway through. A runbook that admits its limits is trusted; one that turns out to be wrong once is never trusted again, and the on-call person will start improvising instead, which loses you the consistency the runbook existed to provide.

Design the on-call rotation for a hypercare period.

Start from the constraint that the people who can resolve issues fastest are the delivery team, and the delivery team has just finished a cutover and is exhausted. A rotation that assumes they are fresh will produce mistakes in week two and resignations in month two, and the interviewer is listening for whether you notice this.

The structure that works is layered. A first line takes everything, does the classification, resolves the known and the trained, and escalates the rest, and it should be the future support team from day one so that the transfer is happening continuously rather than at the end. A second line of functional and technical people who know the system handles what first line escalates, working normal hours with an on-call extension. A third line is a named expert per component, reachable for severity 1 only, and explicitly not on a rota, because you cannot rota a person who is the only one who knows something. Their existence is a risk you name rather than a design you defend.

Then the rules that make it survivable. Nobody is on call for more than a defined stretch without a break, and that break is protected rather than nominal. Being on call overnight means not being expected in the working day, which sounds obvious and is violated constantly during hypercare because the same people are also fixing things. Cap consecutive nights. And staff for the escalation rate you observe rather than the one you planned, revisiting weekly, because week one's rate is not week three's.

The commercial point worth adding, particularly in a consultancy interview, is that hypercare on-call is frequently unfunded and invisible: the delivery team simply absorbs it, it does not appear in the plan, and the burn shows up as the next project starting late. Making it explicit in the resourcing is a lead-level behaviour.

How do you hand over across time zones without losing anything?

Treat the handover as a defined artefact rather than as a conversation, because a conversation across a time boundary is either impossible or expensive.

Every open item carries a current-state note that is sufficient for someone else to continue: what is known, what has been ruled out, what was tried and what happened, who has been contacted, what the next intended step is, and what must not be done. That last field is the one people forget and the one that prevents the standard cross-shift failure, which is the incoming shift repeating an action the outgoing shift had deliberately avoided. Write the notes as you go rather than at the end of the shift, because a note written in the last ten minutes is a summary and a note written during the work is a record.

Overlap the shifts by a real interval rather than a token one, and use it for a verbal pass on the severe items only. The written record carries everything; the conversation carries the judgement and the things that are hard to write, like "the client's operations manager is upset and needs handling carefully".

Then hold single ownership of severe incidents across the boundary. A severity 1 does not change hands merely because a clock did; it is handed over deliberately, with an explicit statement of who now holds it, or it stays with the original owner who stays awake. The failure mode with a follow-the-sun model is that a severe incident is handed round three times in a day and each shift starts its investigation from the beginning, so twenty-four hours produce eight hours of progress. Explicit ownership transfer with a stated summary is what prevents it.

Two smaller mechanisms are worth naming. Keep one channel per incident as the record and make it the only one, so that reconstructing state does not require reading four chat threads and someone's direct messages. And publish a rolling status document that is current at all times rather than a set of point-in-time updates, because an incoming shift needs the state now, not the history of announcements about it.

The support team was not in the room during the build. How do you transfer knowledge to them?

By moving the transfer into the hypercare window rather than treating it as an event at the end, and by measuring it rather than declaring it.

The mechanism is that the support team takes real tickets from day one, with the delivery team behind them rather than in front of them. Every ticket the delivery team resolves directly is a ticket the support team did not learn from, so the default routing goes to support and escalation is the exception, even in week one when that is slower. It is slower, and that cost is the price of the transfer; a programme that optimises the first week by bypassing support has bought speed with capability.

Around that sit the supporting mechanisms. Support writes or updates the runbook for each issue class as it is resolved, which means the documentation is produced by the people who will use it, in their own language, at the moment the knowledge is fresh. Shadowing runs in both directions: support sits with the delivery team early, and later the delivery team sits behind support and says nothing unless asked, which is uncomfortable and effective. And there should be a deliberate reverse-handover session per component where support asks the questions rather than the delivery team presenting, because a presentation transfers what the presenter thinks is important and a question session transfers what the recipient needs.

Measure the transfer with a proportion: what fraction of tickets in the last two weeks were closed by support without escalation, split by issue class. That number is the honest evidence for the exit gate, and it is measurable rather than assertable, which is the whole point. A rising curve is the transfer working. A flat curve at a low level, three weeks in, means the escalation route is being used as the primary route and the transfer is not happening, whatever the sessions calendar says.

Add the honest caveat: some knowledge does not transfer within any realistic window, particularly deep knowledge of a component that was built by one person over a year. Name those components, accept that escalation to a named individual is the arrangement for them, and put a plan against it rather than pretending the handover was complete. A closure pack claiming full transfer that everyone knows is untrue is worse than one that names two residual dependencies with a plan.

Rollback, parallel running and reconciliation

When does rollback stop being possible?

When the cost of reversing the accumulated state exceeds the cost of fixing forward, and the point that happens is determined by data rather than by the plan.

Work through the mechanisms. New data written only into the new system has no home in the old one, so a rollback either loses it or requires a reverse migration that was never built and never tested. External parties have received output with new identifiers, new formats or new references, so the outside world has state that the old system cannot reproduce or reconcile against. Downstream systems have consumed and committed transactions, so reversing your system does not reverse theirs. Legal and financial documents have been issued, and an invoice or a regulatory submission cannot be unissued. Decommissioning has begun: licences cancelled, environments torn down, the legacy interfaces switched off, and in the worst cases the legacy hardware already returned. And the people have moved, because the operations team has spent a fortnight learning the new process and reverting means reverting them too, which is not free.

Those close at different rates, and that is the useful structure to give in an interview. The technical ability to revert typically survives for days. The data reversibility degrades continuously from the first transaction. The external-commitment barrier is a step function that closes the moment the first document goes out. And the organisational barrier hardens over weeks.

flowchart LR
    accDescr: The reversibility window closing left to right after cutover, from reversible with data loss only, through needing a reverse migration, external commitments issued, and legacy decommissioned, with dashed arrows from the first three states to fix forward, which is the route that remains as the others close.
    A[Cutover] --> B[Reversible with data loss only]
    B --> C[Reverse migration needed]
    C --> D[External commitments issued]
    D --> E[Legacy decommissioned]
    B -.-> F[Fix forward]
    C -.-> F
    D -.-> F

What matters in that progression is that the dotted paths become the only paths well before anyone declares rollback closed, and organisations routinely carry a rollback plan in the governance pack for weeks after it has stopped being executable. The stronger practice is to define the go and no-go decision point in advance, in hours rather than in feeling, and to state explicitly at that point whether the plan is now retired. Retiring it deliberately is a decision; letting it lapse is a hazard, because a plan everyone believes exists changes how they take other risks.

Day two of a go-live and something serious is wrong. How do you decide whether to roll back?

Decide against criteria set before go-live, and say so first, because the answer to this question is largely that the decision should not be being invented now.

The criteria are the things that, if true, mean going back regardless of sunk cost: a core business process cannot be performed and has no workaround, data is being corrupted in a way that cannot be reliably repaired, a legal or regulatory obligation cannot be met, or the estimated time to fix forward exceeds what the business can survive. Each of those needs to have been agreed with the business before the cutover, when everyone was calm, because at hour thirty-six the delivery team is invested and the business is frightened and neither is in a position to write good criteria.

Then the assessment, in order. Bound the impact: what exactly cannot be done, by whom, and what is the cost per day. Establish whether a workaround exists that is sustainable for the time a fix would take, and be honest about sustainable, since a workaround requiring six people to work evenings is sustainable for three days and not for three weeks. Estimate the fix time with an explicit confidence, and apply the standard correction that hypercare fix estimates are optimistic because the cause is not yet fully understood. Then estimate the rollback cost properly, including the reverse data problem, the external commitments already made, and the fact that rolling back means doing the cutover again later with a demoralised team and a business that has lost confidence.

The two things interviewers listen for. First, whether you treat rollback as a serious operation with its own risk rather than as a safe default, because a rollback executed in a hurry on day two, from a plan rehearsed once, is itself likely to go wrong. Second, whether you know whose decision it is. The technical assessment is yours. The decision belongs to the business owner who carries the consequence, and presenting them with a clear bounded choice and a recommendation is the job. An engineer who rolls back a business system unilaterally has made a commercial decision on someone else's behalf, and an engineer who refuses to recommend has abdicated the part that was theirs.

The related engineering question, of whether your deployment mechanism can support reversal at all, is treated in designing a deployment pipeline with safe rollback, and the point that a change can be valid and still catastrophic is made in a reviewed config change that takes the fleet down.

What is parallel running, and when is it worth the cost?

Parallel running means operating the old and new systems simultaneously over the same inputs for a period, and comparing the outputs. It is the strongest evidence available that the new system is correct, and it is expensive in a way that is consistently underestimated.

The cost is not the infrastructure, it is the people. Somebody has to enter transactions twice, or maintain a feed that keeps both populated, and somebody has to investigate every difference. The volume of differences in the first days is always higher than planned, most of them are explainable and none of them are explained until a human looks. Running two systems also means the operations team is doing two jobs during the period they are least able to, and the second job is the one they are worst at.

So it is worth it where the cost of being wrong is high and where wrongness is not otherwise detectable until much later. Financial calculations, billing, payroll, regulatory reporting and anything where an error compounds silently are the standard cases. It is not worth it for systems whose output is immediately and obviously visible to a user, because the user is a faster and cheaper detector than a parallel run.

There is also a partial form worth naming, because it gets you most of the value for much less: run the old system in shadow over the same inputs without anyone acting on its output, and compare automatically rather than manually. That works where the old system can be fed programmatically, and it turns a staffing problem into an engineering one, which is usually a better trade.

The discipline that makes any of this useful is agreeing in advance what a tolerable difference is and what happens when the threshold is exceeded. A parallel run producing differences that nobody has committed to acting on is theatre. Every difference gets a classification and an owner, and a class of difference that is accepted gets accepted explicitly with a reason recorded, because "we looked at it and it was fine" from three weeks ago is not evidence anyone can rely on at the gate.

How do you reconcile after a data migration, and what do you do about the differences?

Reconcile in layers, because the layers catch different failures and the cheap ones catch most of the volume.

Row counts by entity and by logical grouping catch wholesale loss: a batch that failed silently, a filter that excluded more than intended, a truncation. Control totals over the numeric fields that matter catch value corruption that counts cannot see, and they are the reconciliation finance will insist on because they map to the balances they are accountable for. Field-level comparison over a sample, or over the whole set where the volume allows, catches transformation errors on individual attributes. Referential checks catch relationship loss, which is the failure that is invisible in every count-based check and shows up months later as an orphaned record nobody can explain. And behavioural reconciliation, meaning running the same business calculation on both sides and comparing the answer, catches the case where every field migrated correctly and the system still produces a different result because a derived value or a configuration differs.

That last layer is the one that distinguishes an experienced answer, because it is the only one that tests the combination of data and system rather than the data alone.

On the differences, the essential discipline is that every difference is classified rather than counted, and that classification drives the action. A difference that is expected because the new model is different is documented once as a class and then excluded from the count, with the reason recorded. A difference caused by a migration defect goes to a correction with a re-run of the reconciliation to prove it. A difference caused by data that was always wrong in the legacy system is a business decision about whether to clean it, and it is one of the standard hypercare surprises, because the migration is the first time anyone has looked closely at that data in a decade.

Two rules make this survivable. Reconcile in both directions, because records present in the new system and absent in the old are a different defect from the reverse and have a different cause. And treat a difference of one as a finding rather than applying a tolerance, at least on anything financial or regulatory, because a tolerance threshold on a compliance reconciliation is how a systematic defect hides inside an acceptable percentage.

Communication and stakeholders

The client executive wants an update every hour. How do you handle that?

Agree to a cadence and then reshape what is in it, rather than refusing. The request is a request for confidence, and refusing it produces less confidence and more calls. Hourly is sustainable if the update is a fixed short format, and the cost of that is far lower than the cost of an executive who has decided the programme is not telling them things.

What goes in the update matters more than the frequency. State the current impact in business terms rather than technical ones: which process is affected and how many people or transactions, not which service is returning errors. State what has changed since the last update, and be willing to say nothing has. State what is being done and by whom. State the next update time. And where you have one, state a current best estimate with an explicit confidence, or say plainly that you do not have one yet and when you expect to.

Sample wording for an hourly update during an active severity 1:

Order entry remains unavailable for the UK team, approximately 40 users, since 09:15. No orders have been lost; those submitted are queued and will process once the service is restored. Since the last update we have ruled out the database and identified the integration layer as the likely cause. Two engineers are working on it with the vendor engaged. We do not yet have a restoration estimate; we expect to have one by 12:00. Next update 11:30.

Three properties of that are worth naming because they are what an interviewer is grading if they ask you to draft one. It leads with business impact and quantifies it. It states the data position explicitly, because "have we lost anything" is the question the reader has and will otherwise ask. And it commits to the next update time, which is what stops the recipient chasing.

The wording that damages trust is the reassuring kind: "we are working hard on it and hope to have it resolved shortly". It contains no information, it implies a timeline you have not committed to, and when shortly turns out to be four hours the next update is read with suspicion. During hypercare you are spending down a limited stock of credibility and there is no way to earn it back quickly.

How do you communicate to a business that is watching every hour and losing confidence?

Recognise that confidence is driven by predictability more than by good news, and design for predictability. A business that is told bad news on time repeatedly will trust the source; a business that is told good news that turns out to be premature will not, and after the second time it will start seeking its own information, which is when parallel unofficial channels appear and the programme loses control of its own narrative.

Practically that means a fixed daily rhythm with a published time, held even on days when there is nothing to say, and a single named person who speaks. It means reporting the trend rather than the snapshot, because a snapshot of eighty open tickets is frightening and "eighty open, down from a hundred and forty, with the four blocking issues resolved" is governable. It means splitting the numbers by class, since telling an executive that sixty of the eighty are questions rather than defects changes the entire conversation and it is true. And it means naming the things that are not yet fixed, before someone else does, because the item you did not mention is the one that defines the meeting.

There is also a specific move worth knowing: give the business a way to see the state themselves rather than only receiving it. A shared view of open items, their severity and their owner reduces the demand for updates substantially, because much of the update demand is a request for visibility rather than for narrative. It also exposes you, which is the point.

And handle the escalation pattern honestly. During hypercare a frustrated user will bypass every process and email someone senior, and the response to that should not be to route them back to the process, which reads as an institution defending itself. Take the item, resolve it or explain it, and then separately fix whatever made the process feel useless to them, because if one person did it, others have decided to and have not yet.

A business user says the system is unusable and their manager wants it escalated. It is one screen and there is a workaround. What do you do?

Take the report seriously as information about experience while assessing it separately as an impact. Those are two different assessments and doing them at once produces either dismissal or overreaction.

The impact assessment is factual: one screen, a workaround exists, how many people are affected, how much extra time per transaction, and how long the workaround must last. That gives a severity and, importantly, a quantified cost. "Fourteen people, six minutes extra per order, roughly ninety orders a day" is a number the business can weigh, and it frequently turns out to be a much bigger number than either party assumed, which is why quantifying it before arguing about it is worth the ten minutes.

The experience assessment is that a user telling you a system is unusable has usually had several smaller frustrations and this is the one they reported. Asking what else has been awkward this week routinely surfaces two or three unreported issues, and it converts an adversarial exchange into a useful one.

Then respond to the escalation without either capitulating or stonewalling. Acknowledge quickly, give the assessment and the quantified impact, state where it sits in the queue and why, and give a date. If the business owner wants it moved up, that is a legitimate exercise of priority and they can have it, provided the trade is visible: something else moves down, and it is named. Priority changes made without naming the displaced work are how a queue silently stops reflecting reality, and it is the same discipline as re-planning when regression is half done and the release is tomorrow, where the recommendation is yours and the decision belongs to whoever carries the consequence.

Exit, the support model and the known-error backlog

How does hypercare exit into a support model, and what changes on that day?

Several things change simultaneously, and the reason exits go badly is that organisations change them all at once without checking that each is ready.

The resolution path changes: issues route to the support tier and reach the delivery team only by exception, if at all. The response commitment changes: the informal hypercare targets are replaced by a contractual SLA with defined measures and possibly penalties, and the two are rarely the same, so an issue class that got a same-day response during hypercare may now sit for two business days entirely legitimately. The change path changes: fixes go through the standard change process and the release calendar instead of being deployed the same afternoon. The governance changes: daily calls become a monthly service review. And the funding changes, which is what makes all the others irreversible.

The specific hazard is the gap between the hypercare experience and the SLA. The business has spent four weeks with same-day fixes from the people who built the system, and on Monday it has a two-day response target and a ticket queue. If nobody has set that expectation explicitly, the first week after exit produces a wave of complaints that the system has got worse, when nothing about the system changed at all. Say the SLA out loud, in examples, before the exit: "an issue like the one on Tuesday would now be responded to within four hours and fixed in the next fortnightly release". Concrete examples land where a table of response times does not.

The practice that reduces the shock is a taper rather than a cliff: a defined period after exit in which the delivery team remains reachable for named severities only, with a hard end date and, ideally, a mechanism that makes the cost visible so it is not used casually. Distinguish that clearly from extending hypercare. A taper is a narrow, time-boxed safety net over an exited service; an extension is a decision that the service is not ready. Confusing the two is how an exit becomes notional.

The underlying subject of how the new commitment is defined and measured is covered in setting an SLO and using an error budget, and it is worth being able to distinguish the internal objective from the contractual agreement in this conversation, because the two get used interchangeably and they are not the same instrument.

What is a known-error backlog, and how do you stop it becoming permanent?

A known error is a defect whose cause is understood and which has not been fixed, carrying a documented workaround. The backlog is the accepted set of them, and it exists because no system exits hypercare with zero defects and pretending otherwise means either lying at the gate or never exiting.

It becomes permanent through a predictable sequence. The workaround is documented and works. The affected team adapts to it and stops complaining, because people are adaptable and a daily manual step becomes normal within about three weeks. With no complaints, the item generates no pressure, so it never wins prioritisation against new work. The project budget closes and the fix now needs operational funding that nobody has requested. The people who understood the cause move on. And eventually the workaround is so embedded that fixing it would itself be a change requiring retraining, so the fix is refused on the grounds of disruption. That is how an organisation ends up with a business process whose third step is a manual reconciliation that exists because of a defect nobody alive remembers.

The mechanisms that prevent it are about maintaining visibility and cost after attention has moved. Every known error carries a named business owner, not a technical one, because the technical owner leaves and the business owner is the one paying for the workaround. Every one carries a quantified workaround cost, in hours per week or per month, and that number is what keeps it prioritisable, because "manual step in invoicing" competes badly against a feature while "eleven hours a week in the finance team" competes well. Every one has a review date rather than an open state, and the review is a decision: fix, accept permanently and change the process properly, or extend with a new date. Accepting permanently is a legitimate outcome, and making it explicit is far better than letting it happen by default, because an accepted item gets designed into the process and a defaulted one stays a workaround forever.

Then report the backlog's size and total workaround cost in the service review, monthly, indefinitely. A backlog that appears on a slide every month with a growing cost figure gets funded eventually. One that lives in a spreadsheet attached to a closure pack does not.

The business wants to extend hypercare. Everything you agreed is met. What do you do?

Find out what is actually driving it before responding, because there are three quite different requests hiding behind the same sentence and they need different answers.

It may be that a specific unresolved thing is not covered by the criteria. That happens frequently and it means the criteria were incomplete rather than that the request is unreasonable. Resolve it as a named item with a plan, and exit on schedule with that item tracked. This is the commonest case and it is why asking is worth more than arguing.

It may be that the support organisation is not ready and everybody knows it, whatever the sign-off says. That is a genuine reason not to exit, and it should be named as such rather than dressed up as system instability, because the remedy is completely different: more transfer, more shadowing, possibly different people, not more defect fixing. Extending hypercare without naming this simply repeats the same four weeks and arrives at the same place.

Or it may be that the business has become comfortable with direct access to the builders and does not want to give it up. That is understandable and it is not a reason to extend. The response is a taper with a hard end and, where the commercial arrangement allows, a visible cost, because the fastest way to establish whether enhanced support is genuinely needed is to make it appear on someone's budget.

What you should not do is extend indefinitely or refuse flatly. An open-ended extension has no exit, because the conditions that would end it were not defined and will not be defined later. A flat refusal on the grounds that the criteria are met is technically correct and destroys the relationship, and it is also risky: the business frequently knows something the criteria did not capture, and a supplier who exits over their objection owns the consequence whatever the paperwork says.

What does a good incident review look like, and how do you know it changed anything?

A review that produces owned, dated, funded actions and nothing else. Everything about the format follows from that.

It happens soon, within days, because recollection degrades fast and because the emotional charge fades into a comfortable narrative within a fortnight. It reconstructs a factual timeline first, from evidence rather than memory, including the times at which people learnt things, which is usually where the interesting delay is. It examines the detection and response as seriously as the cause, because "why did it take fifty minutes to notice" and "why did the first responder not know that runbook existed" are more generalisable findings than the specific defect. It stays away from individual blame, not out of politeness but because a review that assigns blame gets less information at the next one, and information is the entire product.

The output is a small number of actions, each with a named owner, a date, and enough definition that completion is checkable. Three real actions beat fifteen aspirational ones, and a review producing fifteen has usually produced none.

How you know it changed anything is the part interviewers press on. Track action completion as a number and report it, because the failure mode is that actions are agreed and never done, and nobody notices because nobody is counting. Look for the recurrence: the same class of incident happening again is direct evidence the last review did not work, and it is worth saying explicitly in the second review rather than treating it as a new event. And check whether the artefacts changed. If a review found a runbook was wrong and the runbook is still wrong three weeks later, the review produced a document. This is the same discipline as working out what a test suite was never going to catch after everything passed and it broke anyway: the value is in fixing the class of blindness rather than the instance.

During hypercare specifically, run these lightly and frequently rather than heavily and rarely. A fifteen-minute review at the end of each day covering what happened and what should change is worth more than a formal exercise per incident, because the changes it produces land while the window is still open and can benefit from them.

What do you hand over at the end, and how do you know the handover was real?

The artefacts are the easy part and they are not the answer. A closure pack contains the runbook set, the known-error backlog with owners and dates, the monitoring and alerting configuration with the thresholds derived from real observation, the architecture and support documentation, the access and escalation matrix, the outstanding risks, and the record of what was changed during the window and why. All of that is necessary and none of it is evidence.

The evidence is behavioural, and there are four measures worth naming. The proportion of tickets closed by the support team without escalation over the final two weeks, split by class, which is the single most informative number. The number of runbooks executed by the support team rather than merely reviewed. Whether the support team has resolved at least one incident of each severity level unaided. And whether the escalation path has been tested rather than documented, meaning someone actually called the number out of hours and it worked.

The test to propose, if you want to say something an interviewer has not heard fifty times, is a deliberate simulation in the final week: raise a realistic incident that the support team has to work end to end, with the delivery team present but silent. It is uncomfortable, it takes half a day, and it reveals in one exercise what four weeks of documentation review does not. Whatever fails in it is exactly what would have failed in week two after exit, and there is still time to fix it.

Then state the residual honestly in the closure pack. Components where transfer is incomplete, named. Known errors accepted, with owners and costs. Monitoring gaps where an alert was silenced and not fixed. A handover document that claims completeness everyone knows is false teaches the receiving organisation that the pack is not to be trusted, and they will then not read the parts that were true.

Judgement under pressure

You are three weeks in, the arrival rate is not falling, and the client is losing patience. What is happening?

A flat arrival curve three weeks in means one of a small number of things, and diagnosing which is the whole task, because they have opposite remedies.

The fixes may not be landing. Check whether the resolved items are actually in production, because during hypercare the gap between "developer marked it done" and "deployed and verified" is where a surprising amount of work sits, particularly if the release path has become a bottleneck. If the fix cycle is slower than the arrival rate, the curve cannot fall regardless of how good the team is, and the remedy is release throughput rather than more developers.

New user populations may be arriving. A phased rollout, or simply a business area that had not started using the system, produces a fresh wave of the same classes you already fixed, and the aggregate curve looks flat while the per-cohort curve is falling nicely. Splitting the curve by user group resolves this in ten minutes and it completely changes the story you tell the client.

New scenarios may be being exercised for the first time. Month-end, a quarterly process, a rarely used product type. This produces bursts rather than a plateau and it is expected, though it will not look expected on a chart.

Or fixes may be generating new issues, which is the serious case. If the regression rate is significant, the team is moving too fast for the verification available, and the remedy is to slow the fix cycle down, which is the hardest thing to propose in week three and frequently the correct one.

Or the classification may be hiding the truth, and the curve is flat because training questions are being counted as defects and users are still learning. Splitting by class resolves it.

The point to make in an interview is that the answer starts with disaggregating the number rather than with reassuring the client, and that in three of those five cases the honest message is good news that the aggregate chart was concealing. A programme that reports only a total is unable to tell that story and is therefore stuck defending a flat line it does not understand.

The delivery team is exhausted and the window has been extended. How do you handle it?

Treat it as a resourcing failure that has already occurred rather than as a morale problem to be managed, because the second framing leads to pizza and the first leads to a plan.

Say the specific risk out loud, because it is concrete: a tired team makes the kind of mistakes that extend hypercare further, and the most likely serious incident in week five is one the team causes. That reframes rest as risk management rather than as welfare, which is the framing that gets it approved.

Then the actions. Rotate people out properly rather than nominally, which means someone is not reachable rather than reachable but not on the rota. Bring in people who were adjacent to the project, even at the cost of ramp-up, because a fresh competent person at seventy per cent is worth more than an exhausted expert at forty. Reduce scope: during an extension, only the things that block exit should be being worked, and the enhancement requests that have crept in should be stopped explicitly and publicly. And close the direct-access channels that bypass the process, because the personal chat messages to individual developers are a large and invisible part of the load.

Then escalate the underlying cause, which is that the extension is unfunded. Somebody is paying for it in a currency that does not appear on the budget, and that will surface as attrition or as the next project starting late. Making it visible is uncomfortable and it is the lead-level behaviour the question is looking for. A candidate who describes only how they would motivate the team has answered a smaller question than the one asked.

A vendor component is the cause and the vendor says it works as designed. You are on day four.

Separate the immediate from the contractual, because they run on different clocks and you need both.

Immediately, you need a workaround in something you control, since the vendor's position means no fix is coming this week whatever the merits. That usually means adapting at the boundary, constraining the input, or moving the affected process to a manual path temporarily. Whatever it is, document it as a known error with an owner rather than letting it become an undocumented adaptation, because during hypercare these workarounds are invented at speed and forgotten immediately.

In parallel, establish what the contract and the specification actually say, because that determines whether this is a defect conversation or a change request, and they are handled by different people at different speeds. If the behaviour contradicts what was agreed, the route is contractual as well as technical and it should be escalated commercially the same day, since vendor escalations run on weeks and starting late costs you the whole period. If the interface never specified it, the vendor is right and the gap is in your own specification, which is worth admitting internally rather than continuing to argue.

The thing to add, because it is what the question is really testing, is that during hypercare you cannot afford to wait for the resolution of who is at fault. Build the workaround as though the vendor will never fix it, and pursue the vendor as though the workaround does not exist. Candidates who sequence those, waiting for the vendor's answer before mitigating, lose days they do not have. This is the same structure as the design position in what to do when a managed service in your region is having a bad day: during the event, your only levers are the ones you already control.

Someone changed something in production to fix an issue and did not tell anyone. What now?

Handle the instance quietly and the pattern seriously, and in that order, because the reverse gets you no more information.

The instance: establish what was changed, whether it is correct, and whether it is captured anywhere. Then bring it into the record, which usually means making the same change through the proper path so that it exists in the configuration of record and will survive the next deployment. The specific hazard is the change that is correct and untracked, because it works, nobody notices, and then a routine release overwrites it and the incident recurs with everyone confident the cause is something new. That is a genuinely expensive failure mode and it is worth describing, because it is the reason this matters beyond process compliance.

The pattern: out-of-band changes during hypercare happen because the proper path is too slow for the pressure people are under, and that is a design problem rather than a discipline problem. If an emergency change takes six hours of approvals and the incident needs a fix in twenty minutes, people will route around it, and telling them not to will not work. So provide a fast path that is real: a defined emergency change procedure with a small named approval group, reachable out of hours, with the documentation completed after the fact rather than before. A fast path that people use is worth far more than a rigorous one they bypass.

Add the detection point, because it is what makes this tractable: configuration drift should be detectable rather than relying on people declaring it, whether by comparing running configuration against the configuration of record or by alerting on changes made outside the deployment path. Anything the system loads and behaves on is a release, which is the argument in what ships without passing the deploy pipeline, and during hypercare the volume of such changes is at its highest and the tracking at its weakest.

What is the worst hypercare you have been part of, and what did you learn?

This is a behavioural question and it is graded on specificity and on whether you take a share of the responsibility.

A strong answer names one engagement, states the concrete failure, and is honest about your own part in it. The generic failures worth recognising, if you need to locate your own experience against them: exit criteria written after the window started, so the gate was a negotiation. A support team introduced in the final fortnight, so the transfer was a document handover and the first month after exit was worse than the last month before it. Data quality treated as a migration workstream that ended at cutover, so the interfaces kept producing the same defects nobody owned. A war room that never stood down, which trained the business permanently to bypass the process. And severity inflation that made the defect register meaningless at exactly the moment it was needed as evidence.

What is graded is the specificity of the learning and whether it changed your behaviour afterwards. "I would communicate better" is not a learning. "We now write the exit criteria into the cutover approval, before the go-live decision, because agreeing them afterwards means agreeing them with people who have already formed a position" is. Interviewers ask this to distinguish people who have been present at a difficult hypercare from people who took something from it, and the difference is entirely in the level of detail.

Everything is urgent. How do you decide what not to do?

Rank by irreversibility and by whether the cost is accruing, not by who is loudest.

Anything corrupting data or producing incorrect external output goes first, because its cost grows with every hour and the repair gets more expensive as the affected population grows. A process that is blocked is expensive and its cost is bounded and constant, so it comes second even when it is louder. A regulatory or statutory deadline is fixed and external, and it does not move regardless of how reasonable the reason. Things with sustainable workarounds come after those, and the word sustainable is doing real work there and needs testing rather than assuming. Enhancement requests, which appear in every hypercare disguised as defects, come last and should be visibly separated rather than quietly deprioritised.

Then make the trade explicit rather than absorbing it. Stating in writing that a piece of work will not be done this week, with the consequence named and the owner informed, is the behaviour that distinguishes someone trusted with scope from someone given tasks. During hypercare the pressure to say yes to everything is at its highest and the capacity to deliver on it is at its lowest, and the gap between the two is where the credibility of the whole programme is lost. The same asymmetry between a loud bounded cost and a quiet accruing one appears in why a one-minute blip can leave you degraded for a day: what determines recovery is how much state diverged, not how long the fault lasted.

How to prepare

Learn the arc well enough to draw it from memory and to say what each stage owns, because most questions in this subject are a probe into one point on it. If you can state the entry criteria, the exit criteria, the four issue classes and the rollback decay in your own words, you can construct an answer to almost anything asked here.

Then rehearse the three answers that carry the most signal, out loud, because their structure is what is graded and structure is the first thing to go under pressure. The first ten minutes of a severity 1: command, impact, fallback, communicate, then diagnose. The classification of an incoming issue: defect, data, configuration or training, with the reproduce-with-clean-input test as the discriminator. And the rollback decision: criteria agreed in advance, bound the impact, honest fix estimate, honest rollback cost, recommendation to the person who carries the consequence.

Practise writing a stakeholder update. Interviewers ask for this more often than candidates expect, and the difference between a vague answer and a paragraph you can produce on demand is very visible. Impact in business terms and quantified, data position stated, what changed, what is being done, next update time. No reassurance without content.

Then bring one real engagement, even a small one and especially one that went badly. A candidate who can say that the known-error backlog they exited with had eleven items, that four of them are still open two years later, and that the reason was that none of them had a quantified workaround cost, is more convincing than any amount of framework fluency. Be honest about what you have not done. Someone who has run hypercare will find the edges of your experience within three questions, and the discovery is far less damaging than being caught overstating.