Which SaaS workflow should you replace first?

AWS describes the strangler fig pattern: new features take over parts of the old system one by one, until the old one can be switched off. With SaaS it works in a similar way, but each part needs its own data boundary, because a correction saved only in the old system will give the employee out-of-date materials.

The first scope has to be separable

Suppose a service company runs clients, quotes and delivery in one package. Preparing documents after a finished service takes the most manual work. The team is considering its own workflow for these materials, keeping quotes and planning in the current tool.

Such a split can be clear: a finished job with the client's identifier goes to the document application, and the person responsible prepares the package. You still have to decide what happens when the job is reopened. If the correction stays only in the old system, the employee may hand over out-of-date materials. This dependency belongs to the first scope, even if it occurs less often than an ordinary finish.

A good candidate has an understandable start, a result the recipient needs and a person responsible for the whole. You can name which information will be read from the current tool and which new records will be created outside it. When almost every step needs a record changed in both places, the boundary needs rethinking.

The choice does not have to fall on the most irritating feature. Sometimes it is so tightly linked to the rest of the package that separating it drags in a large part of the system. Compare several candidates by how much the problem matters, the dependencies and how the result can be checked. A smaller area can give the company experience in ordering and maintaining its own software.

Two systems need agreed cooperation

AWS describes gradually replacing a system's features in the strangler fig pattern: the old and new parts coexist during the switch. The description concerns application modernisation and has defined technical limits. With SaaS, whether such a split is possible has to be checked separately in the available integrations and the terms of the service.

Before you build, ask the current product's vendor whether configuration or an available add-on will solve the chosen problem. Your own part can also stay a permanent extension, if the rest of the package serves the company well. Deciding on the first stage does not commit you to rebuilding every feature later.

In the cost comparison, include the period when both tools work together. Access to the old system, the connections and help for users may still be needed. Do not assume that launching one application will automatically reduce your commitment to the SaaS vendor. That depends on the terms of use and on who still needs the product.

The switch has an owner on both sides

Open cases need a clear decision on where they will be finished. In the example, the company can leave started document packages in the old flow and send new ones to the application, or agree to move them. An employee should be able to check the right place easily, without comparing two lists.

The order should cover how missing updates are clarified and who is responsible for the connection. Also settle access to the code, the documentation and a data export with references to the original jobs. Then the next stage or a change of contractor does not require working out the meaning of the records from scratch.

Talk to Syntalith about the task your team most often does outside SaaS. Using it as the example, we can discuss the boundary of the first scope, the dependencies and the terms for keeping the rest of the system. 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.