When to retire a custom SaaS extension

The extension was built because the system lacked a feature, and over the years it may have taken on more work than its description says. A short description of the vendor's new feature usually covers the main case, while the exceptions stay in the extension. Before the shutdown, the process owner names the ones that are still needed.

The new feature covers part of the old need

Suppose a company commissioned an application that sends notifications about changes in a register. Over time it was extended with a reminder to the manager if the named person had not picked up the case. Now the current tool offers its own notifications. The administrator sees a chance to simplify support, but the manager still needs to know about cases left without a response.

First establish which behaviours are actually used. Ordinary notifications may be enough, because the team has changed the way it works. The reminder you need may be configurable in the product. You can also keep only the part of the extension that still solves a specific problem. The choice should rest on needs visible in current work.

For example, Microsoft Lists and SharePoint let you create rules that send notifications about changes in a list or library. Configuring them needs the right permissions and is subject to the limits described. Such a feature can cover part of a custom extension; check its usefulness in the environment you use.

Compare the user's whole working day

In the example, what matters is whether the user gets the right message, can go to the case and knows what to do. The manager should see how they will spot a missing response after the change. If the current extension combined data from several places, the comparison must cover those dependencies too.

The new feature may need a different plan, different settings or a different way of granting access. Confirm these conditions with the administrator or the vendor. Set them against the work needed to maintain your own component: integration changes, problem handling and development. Keeping the existing code running needs its own justification.

Also look at the exceptions added over the years. Some may still matter; others may be left over from a finished project or a team change. The process owner should name the behaviours the company is choosing to give up. It is a chance to simplify the work, as long as the people involved understand the effects.

Switching off the add-on needs preparation too

Open cases may have actions scheduled in the current extension. Agree whether they will be finished there or taken over by the new feature. During the switch, avoid double messages and spot cases that ended up in neither flow. The company should know who clarifies such cases.

If the extension keeps its own history, decide where it will be available after the shutdown. The code and documentation can stay in the company's archive, even if the application stops running. Clean up access and connections within the agreed scope, with a person responsible for each environment.

After the change, support may be split differently: the product administrator takes over the configuration, and the contractor stays responsible for the integration that is kept. Write down this boundary and the rules for exporting data. Then a user knows where to report a problem, and the company can later change who looks after the remaining code.

Talk to Syntalith about an extension that now duplicates a product feature. We can discuss what it still does for the team and what scope of assessment will let you decide whether to simplify it, keep it or retire it. Pricing information is on the pricing page.

What it costs

Where to start

In the free review we choose one process and count the volume and the team's working time, and within 2 working days you receive a written summary with a price. We build the automation as part of AI automations, from €3,000 net.