Who maintains custom software after a SaaS replacement?

An application prepares warehouse orders from data in the order system. After a change on the other side, new orders stop appearing, and the warehouse employee sees an empty queue. A developer wrote the code, an administrator looks after the server and the order system's vendor supports its product, so without agreements everyone points at someone else.

One failure crosses several companies

Suppose an application prepares warehouse orders from data in the order system. After a change on that system's side, new orders stop appearing. The warehouse employee sees an empty queue, but cannot tell the cause. They need to know where to report the problem and how to check which orders are waiting.

The agreed support should name the person or team that leads the investigation from the report to restored work. Some steps may need the order system's administrator, and the user should not have to work out alone which vendor gets the next part of the problem. The process owner on the company's side sets the priority and agrees how to work during the outage.

Also tell apart fixing an application bug, adapting to a new version of an outside system and developing features. These kinds of work may follow different rules. The buyer should understand what the agreed support covers, what needs a separate order and who assesses a report first.

Maintenance can be organised in several ways

Your own team is a natural candidate if it has the skills and time for the application. The contractor knows how it is built, but settle its availability after the project ends too. A separate partner can take over maintenance if it gets the materials and access it needs. In every option, the company needs a person who decides on business changes and receives information about problems.

Support for a ready SaaS also has a defined scope. Before you give it up, establish which duties the vendor carries out today and which already belong to the company's IT. The comparison should include support hours, integration handling and responsibility for data. The number of features in the application does not describe the work needed to keep it running.

Microsoft, in its guidance on recovering Power Platform services, covers critical processes, dependencies, responsible people and testing the recovery plan. It is a useful reference point when you discuss the continuity of your own application. The specific scope should follow from the program's role in the company.

Not every application needs the same availability. A tool used once a month and a system that handles daily warehouse releases have different consequences when they stop. Discuss them before you choose a support model. That lets you order support that matches the team's work, without picking the most elaborate option by default.

The next maintainer needs more than the code

The company should know where the data and backups are, and who controls the accounts needed for the application to run. Agree access to the repository, the documentation and the environment so that another person can take over maintenance. One contractor's personal account can make it hard to hand over even a well-documented program.

Also settle the exit: exporting the data with its links and handing over information about open problems. A change of maintainer need not mean a change of application. The new team needs time to get to know it and a clear moment when it takes over the reports.

Talk to Syntalith about what will happen in the company if the planned application stops working. That conversation helps define the scope of maintenance and the responsibilities worth including in the purchase. 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.