Behavioral Interview: Tell Me About Retiring a Legacy System Without Losing Users

Prompt and context

The interviewer wants evidence that you have driven a change with real historical baggage. A legacy system may still run while consuming on-call time, failing a security requirement, or blocking a new product. Explain how you decided to retire it, migrated users, and handled disagreement.

This is not a request for a technical rewrite or a story that credits “teamwork” for everything. The answer should make your judgment, actions, evidence, and result audible.

What the interviewer is testing

They are testing whether you start from user workflows rather than system age, use data to find affected people, make risks and ownership visible, and keep the user goal intact through disagreement and execution. Amazon’s interview guidance emphasizes STAR, specific individual contributions, and measurable results; Google SRE’s retirement case emphasizes user workflows, communication, and migration tooling.

Questions to clarify first

Clarify whether “retire” means stop new users, keep a read-only archive, shut down completely, or replace an internal process. Then clarify your role, scope, deadline, available replacement, and irreversible risks. If company data cannot be shared, label figures as anonymized real measurements or interview assumptions.

A 30-second answer structure

Use five sentences: the context and cost; the goal I owned; how I used access data and user interviews to choose migration cohorts; how I designed dual-run, rollback, and communication; and the result, lesson, and next change. Use “I” for actions and numbers for outcomes.

Step-by-step analysis

Step 1: Translate “legacy” into testable problems

Do not announce shutdown because the stack is old. Quantify maintenance hours, incidents, cost, compliance gaps, and critical workflows still using it. Segment by user, workflow, data size, and access frequency to find exceptions the replacement cannot yet cover. Google SRE used access patterns to understand workflows instead of deciding from system statistics alone.

Step 2: Build migration evidence and a smallest safe path

Define a target state for each user group: direct migration, conversion tooling, read-only archive, or a time-boxed extension. Provide a compatibility checklist, data reconciliation, rehearsal environment, and explicit stop conditions. Start with a low-risk cohort so replacement capability and migration cost are measured in real use.

Step 3: Handle disagreement and stakeholders

Turn objections into risks about data loss, work interruption, unclear ownership, or missing replacement capability. Build a risk list and weekly decision record with support, customer service, security, and the replacement owner. Debate with evidence; after a decision, name the executor and pause authority so disagreement does not become indefinite delay.

Step 4: Design dual-run, rollback, and communication

Keep the old system read-only or reversible during migration and give each cohort a verifiable completion signal. Communicate impact, reason, deadline, steps, and help channels early; if a batch fails, state the fact, remedy, and next update. False positives that alarm unaffected users and false negatives that miss affected users both erode trust and create service work.

Step 5: Define outcomes and learning

Track migration completion, critical-workflow success, rollbacks, incident hours, help requests, and maintenance hours. Do not report only that “the old system was shut down”; show whether affected users completed work, operating load fell, and which exceptions remained. The retrospective should record wrong assumptions, early signals, and validations to move earlier next time.

High-quality sample answer

I once owned the retirement of a reporting workflow still used by a small group of customers. It consumed about 20 hours of manual maintenance each week. The replacement covered most queries, but high-volume customers feared historical-data mismatches. I segmented users by access logs and workflows: 82% could migrate directly, while 18% needed historical conversion.

I set the goal as completing low-risk cohorts first, not shutting down immediately. Engineering produced reconciliation reports for both outputs, support prepared customer-grouped notices, and I owned a weekly migration board with pause criteria. After a two-week pilot, critical-report consistency reached 99.9% with no rollback. For the remaining users, we supplied conversion tooling and a read-only archive and extended the final deadline once.

Maintenance fell from about 20 hours to 4 hours per week, and every customer with remaining access had a replacement path. The retrospective found that we had underestimated one region’s export format, so we added region and export type to the initial segmentation instead of discovering it near the deadline.

Common mistakes and improvements

• Saying only “the system was old”: add user impact, maintenance cost, and replacement evidence.
• Telling a rewrite story: explain workflow discovery, cohorts, and communication.
• Calling skeptics blockers: show the risk evidence behind their concern and your response.
• Reporting only migration percentage: add critical-task success, rollback, and help volume.
• Claiming zero risk: name the read-only, rollback, or extension path.

Follow-up questions and responses

What if the replacement is not ready for every user?

Keep a documented exception path: read-only archive, conversion tooling, or a time-boxed extension. Define the owner and exit condition for each exception instead of forcing a risky cutover.

How did you convince a stakeholder who opposed retirement?

I asked which failure they were protecting against, measured that workflow, and ran a small migration to test the replacement. If the decision still went against their preference, I recorded the risk and committed to the agreed plan with a pause condition.

What would you do if migration caused data loss?

Stop the batch, preserve the old source, identify the affected records, and communicate a concrete recovery timeline. After restoring service, add an automated reconciliation check and revise the next batch gate.

How do you know the project succeeded?

Use user-outcome and operating metrics together: critical workflow success, migration completion, rollback and support volume, plus maintenance hours. A closed system without a safe user path is not a successful retirement.