Not every ugly APP must be torn down, and not every client that still opens deserves another patch. Put “revise” and “rebuild” on a scale. Look at three things: is the floor still using it, can the APIs continue, are certificates and accounts still in the company’s hands. Old visuals can be changed. Wrong IA, a native project nobody can compile, orders split from the mini program—more patches will cost more than a rebuild.
A common mistake: clinging to a five-year-old native shell to “keep installs.” If people rarely downloaded it, installs are not an asset. See What to do when nobody downloads the APP. If the main entry should have been a mini program and you keep adding modules to the old APP, you are investing in the wrong container. Compare Mini program or APP as the main entry.
After you decide to rebuild, the fear is “new package listed, old logins all die, the floor stops that day.” List push certificates, bundle IDs, deep links and QR codes already printed on devices. Keep what you can. Migrate accounts once so employee and store sides do not each log in separately. The back office must be one set. See Why one back office keeps multi-end data from forking. Rebuild does not mean every role in one shot: employee reporting first, then members, then suppliers. Pace is in From brief to launch: how a mobile build runs.
If it is simply unused, walk the diagnosis list first. You may not need a rebuild. See Launched, unused: how to diagnose. A template shell you cannot change is close to a rebuild. See A template mini program is almost as bad as none. DaXi reviews an old APP by source ownership, store account, real DAU and the three buttons the floor still taps—then says revise or rebuild. We do not default to teardown. Send the production bundle ID and back-office URL to the Apps & Mini Programs to start the assessment. Cost is in What APP, mini program and H5 cost, and how long they take.
A fourth weight on the scale: compliance and OS version. An old package that still asks for wide permissions, cannot pass a new review or depends on an unmaintained framework will fail the next store review if you keep revising. Rebuild is often shorter then. Conversely, if only the splash and fonts are dated and scan-and-report is still stable, a rebuild wastes muscle memory the floor already has. Ask the crew “which three buttons do you tap after open.” Those three stay. The rest can go.
Someone on the floor is still reporting on the old package. Sudden death pushes them back to paper. Cut over after device acceptance. Give a two-week overlap. Changing the bundle ID on rebuild restarts the download funnel. If you can keep the bundle ID and login state, do not make the floor hunt a new entry.
Expired enterprise signing or push certificates look like “rebuild.” They are ops. Get the accounts back to the company first, then talk engineering. If certificates are not in company hands, any revise dies again at the next expiry.
Send the production bundle ID, who owns the store account and the three buttons the crew still taps. We will say revise or migrate from whether the APIs can continue—not a default teardown.