Legacy Plan Management

Classification starts from two objects: plan carries the name, ageInMonths, dataAllowance, internationalMinutes, and feature list under review, and customer contributes tenureInMonths, the field that decides whether legacy status becomes protected.

Categorization runs on name patterns plus age under a first hit policy: a plan.name matching contains($, "Legacy") with plan.ageInMonths > 36 and customer.tenureInMonths > 24 is classed 'legacy' with isGrandfathered true, while a Legacy name older than 24 months without the tenure requirement stays 'legacy' but ungrandfathered. Names containing "Value" or "Essential" map to 'value', "Premium" or "Unlimited" to 'premium', and everything else defaults to 'standard'.

Requiring both plan age and customer tenure before grandfathering is deliberate: protection is meant for people who have actually held the old terms, not for anyone who recently landed on an aging SKU. Pattern-matching the plan name is a pragmatic classifier for real catalogs, where years of marketing-named plans rarely share a clean taxonomy field, and the ordering matters because 'Legacy Unlimited Family Plan' should hit the legacy rows before the 'Unlimited' pattern can claim it as premium.

Entitlements follow from the category and grandfathered pair, checked top-down. A grandfathered 'legacy' plan keeps its own plan.dataAllowance and plan.internationalMinutes with retainSpecialFeatures true; an ungrandfathered legacy plan keeps its data but drops to 10 international minutes and loses special features. 'premium' plans get fixed grants of 50 GB and 100 minutes, 'value' plans 15 GB and 0, and the fallback row issues the 'standard' package of 25 GB and 50 minutes, each with a customer-facing description string.

Echoing the original allowances for protected customers is the whole point of grandfathering: the carrier honors sold terms rather than substituting a catalog value. Trimming perks like international minutes for non-protected legacy plans, while the next node offers a modern equivalent, gently narrows the gap between old and current products so migration becomes attractive instead of forced.

Catalog targets are assigned from the same category and grandfathered inputs: protected legacy customers keep their own plan.name and plan.id as the recommendation, while ungrandfathered legacy plans map to 'Telco Essentials Plus' ('PLAN-ESS-001'). 'premium' resolves to 'Telco Premium Unlimited', 'value' to 'Telco Essentials', and the default row to 'Telco Standard' ('PLAN-STD-001').

Collapsing an arbitrary set of legacy names onto five current SKUs is how catalog rationalization actually gets done: billing, care, and CPQ systems all get a single recommendedPlanId to act on instead of parsing historical product names. Passing the untouched plan identity through for grandfathered accounts keeps the mapping table safe to run on every customer, protected or not.

Migration is the final gate, driven by planDetails.category and planDetails.isGrandfathered. Grandfathered legacy customers get migrationEligible false with the note 'Protected legacy plan - migration not recommended', ungrandfathered legacy plans become eligible with 3 months promotional pricing on Telco Essentials Plus, and the catch-all marks current catalog plans as needing no migration.

Pairing the eligibility flag with ready-made offer text lets retention campaigns act on the output directly, and sweetening the move with a time-boxed promotion instead of forcing it reflects how carriers retire plans without triggering churn or complaints. Excluding protected customers keeps the tool aligned with the tenure commitment made in the identification step.

Response shaping happens last: the plan, planDetails, and customer keys are set to null so intermediate working data is stripped and downstream systems receive only the decision outputs, such as simplifiedPlanName, recommendedPlanId, migrationEligible, and migrationOfferDetails. Trimming the payload here keeps internal classification detail from leaking into consuming channels.