Retiring a no-code app that duplicates a supported system

Retire a duplicate no-code app only after the supported system can take over the work people actually use it for. Decide where new work begins, what happens to open items and which old records remain necessary. Then stop new entries, confirm the handover and remove obsolete access and connections under the organisation's records decision.

Confirm the tasks are duplicated

Compare tasks, not app names. A staff-built tracker may look like a duplicate of a supported service system while holding an exception queue, note or report users need. Ask users to show an ordinary task and a difficult case, then identify the information and decision each requires.

Give every material function a disposition: use the supported system, add an approved missing function, retain controlled historical access or stop doing the task. If a missing function is essential, assign an owner and acceptance condition before setting a shutdown date. Running both tools without a rule for new work can leave competing answers to the same business question.

Decide what happens to records

List open items, completed records, attachments, identifiers and decision history that may still be needed. Name the system that will own each item after the move. A row export may omit files, relationships or the meaning of a status, so inspect a representative sample before relying on it.

In a hypothetical facilities tracker, an open repair might become a case in the supported system, with its former ID retained as a reference. Completed repairs might need controlled historical access only. These are possible dispositions, not a universal retention rule. The records owner should determine what must remain available and for how long.

If the old app holds personal information and the organisation is subject to the Australian Privacy Principles, APP 11 requires reasonable steps to destroy or de-identify information that is no longer needed for a permitted purpose.

APP 11 has exceptions, including where retention is required by Australian law or a court or tribunal order, or the information is part of a Commonwealth record. Assess the actual records before deletion or indefinite retention.

Key compliance considerations under APP 11

Move new and open work

Choose a date after which users start new work in the supported system. Tell them where to find existing items and who handles work already in progress. Give a named person responsibility for reconciling remaining old items with their destination. Keep an old-to-new ID mapping where staff may need to follow an earlier reference.

Acceptance evidence should show that the supported system handles the required ordinary and difficult tasks, and that open items have the intended owner and state. Record observed results when the team performs those checks. If an essential path fails, resolve it or narrow the cutover before declaring the old app replaced.

Close the old app and its dependencies

Once new work has stopped and required history is accounted for, identify the app's shares, scheduled actions, notifications, connections, files and data source. Check whether another workflow uses a shared component before removing it.

Microsoft documents dependency checks for Dataverse solution components and an administrator route to delete Power Apps; those are product-specific controls. Deleting an app does not by itself establish that all connected records, files or permissions were disposed of.

Record who approved retirement, where work moved, what historical access remains and when old grants and credentials were removed. Mark the app retired in the inventory. Low usage can prompt a review, but the replacement task, records and users determine whether retirement is ready.