What actually goes dark the week you leave a legacy app

The week a team retires an old client, leadership still asks for the same Monday chart. Downloads from the store usually survive because the store, not the app, produces them. Almost every figure that depends on an event inside the binary does not.

In Penang we still see destination builds that ship with a vendor’s sample events: session_start, purchase, and a generic screen_view. The legacy app, meanwhile, had a decade of names that nobody wrote down — ‘OrderConfirmV3’, a Malay-language screen title, a user property that only fire on the Android flavour. Those strings are how last year’s funnel was built. They will not appear in the new property unless someone copies them, on purpose, into the new instrumentation notes.

Three losses show up so often they are worth listing. First, retention cohorts keyed on an old anonymous identifier. If the destination SDK mints a fresh ID, every ‘returning user’ looks new. Second, funnels that mixed a screen name with a button event; the new build often logs only the screen. Third, any ratio that used a denominator the old crash library provided and the new one does not — notably ‘sessions with a network error’.

None of this is mysterious. It is a paperwork problem that gets treated as a vendor switch. Before freeze, print the last twelve Monday reports and highlight every number that comes from inside the app. That highlighted set is the measurement surface the destination build has to honour. If a number cannot be mapped, write the footnote you will need on the week of cutover, while people still remember why the old chart was shaped that way.