Replacing your business system takes a staged plan

You have received a quote for a new business system. The finance department owns the project and the supplier has proposed a launch date. Meanwhile, the website pulls prices from the old system, the warehouse sends stock levels and the customer portal shows open orders.

So replacing your business system needs a staged plan that covers the entire order chain. Each stage should leave behind approved checks and a clear decision. Otherwise you risk discovering the channels' dependencies only when customers start ordering.

The stages that steer your business system replacement

Start by giving the steering group the mandate to stop the project. A gate only works when someone can refuse the next step. The project manager gathers the material, the process owners approve the business results and the steering group decides on money and further work.

Use five gates with concrete exit criteria. At each gate, the steering group decides whether the project continues, is replanned or is stopped. Approved data quality and documented deviations should carry through the whole programme. Any outstanding deviation needs a named owner and an agreed way of handling the consequences.

The pre-study sets a baseline for processes, data, integrations, cost and benefit. Document how work is done today, including manual corrections, waiting times and dependencies between departments. To pass, you need a signed-off baseline and a budget reserve for data cleansing, testing, training and parallel running.

Solution design sets the target architecture and priority flows. Decide which ways of working carry over and which change. To pass, you need a documented data model, agreed ownership and migration rules.

The integration test follows the whole chain from order to reported order status, including flows to the website, EDI, PIM and portal. To pass, errors must be below the agreed tolerance and retries must work.

User acceptance testing puts real orders, prices and permissions to the test. People from the business carry out their own tasks and the process owners approve the workflow. A demo with the supplier's sample data is fine as an introduction, but it leaves your exceptions untested.

The dress rehearsal tests a production-like run and the ability to roll back. To pass, you need a signed reconciliation of finance, stock and orders and a tested rollback plan. An approved gate should be auditable afterwards, so keep the test material, the deviations and the name of the person who approved the result.

In the Swedish National Audit Office's review of strategic digitalisation projects, 44 percent of completed or ongoing projects were delayed, and completed projects cost on average around 21 percent more than the original budget. These figures apply to the public sector. They are not a forecast for your company.

A reserve at that level can serve as a starting point for discussion, but it needs to be tested against your actual risks. Budget explicitly for data cleansing, integration testing, training, time-limited parallel running and change management. Also state who is allowed to use the reserve.

Decide on the measurement points before implementation: order accuracy, stock accuracy, invoice lead time, integration errors and actual usage. Then the process owners can compare the outcome with the starting point. When several companies are involved, a limited pilot is often a better start, provided shared flows can be kept together during the transition.

Map the flows before you choose a system

Finance can own the investment while purchasing and sales have to do most of the change work. That is why every process owner involved should describe their flow before the system is chosen. Otherwise the supplier gets a set of requirements where the accounting is detailed and the order chain is left open.

According to the Swedish Agency for Economic and Regional Growth's survey Företagens villkor och verklighet 2023, 55.3 percent used digitalisation to a large extent for administration. The corresponding share was 32.6 percent for purchasing and 22.5 percent for sales.

The differences say something important about preparation. A well-digitalised finance flow can sit next to a purchasing flow that still relies on spreadsheets. Both need a place in the requirements, but they need different support during implementation.

Have the process owners describe a real deal from start to finish. Follow the customer's identity, agreed discount, item number, unit, VAT code and delivery terms. Mark where someone re-enters the same information and where someone has to interpret an exception.

For each set of information, state which system is the source. The customer register can have one source, product descriptions another and price calculation a third. Also write down who may change the data and how the change reaches the recipients.

Cloud delivery belongs in the same review. According to Statistics Sweden's statistical database, 72 percent of Swedish companies with at least ten employees bought cloud services in 2025. The figure covers cloud services in general and says nothing about cloud-based business systems.

Cloud delivery can reduce your own server operations. You still need to decide how data is exported, who administers permissions and who tests upgrades.

Finish the mapping with a flow inventory that the process owners sign off. It should contain source, recipient, exceptions, responsibility and approval requirements. Attach an example of the information that is actually sent.

Otherwise a low licence price can be followed by extensive work in the website and portal. That happens when the same customer data has to be interpreted differently in each channel. A shared information model gives you a better basis for judging the total cost before you sign.

Orders and stock have to work in your channels

A customer places an order at an agreed price. The portal confirms the order, but the business system rejects the item's unit. If nobody owns the error, the customer may think the delivery is booked while the order department has no valid order to work from.

According to Statistics Sweden's figures on IT use in businesses, 36.7 percent of Swedish companies with at least ten employees sold online via the web and/or EDI in 2024. For these companies, replacing the business system directly affects what the customer sees in the ordering flow.

Set up an integration contract for each flow. The contract describes what the sender promises, what the recipient accepts and what happens when something goes wrong. It should be usable both during development and when troubleshooting after launch.

For item data, the contract needs to define identity, unit and activation status. For prices, it needs to describe customer linkage, currency, discount and validity period. The stock flow needs to separate physical stock from the quantity the customer is actually allowed to order. The order to the business system needs acknowledgement, duplicate protection and error handling. The order status coming back needs an agreed meaning for each status, partial deliveries and a fixed update order.

State the direction, transfer frequency and permitted delay for each flow. Also document the error queue: who gets the alert, who fixes the root cause and who resends the message. An automatic alert only helps when the recipient has the mandate to act.

The same rules need to work in the customer portal, reseller portal, spare parts portal and any EDI flows. In the walkthrough of e-commerce and the business system, the link between sales channel and order handling is central. The customer's confirmation needs to match what the business can deliver.

Test what the customer sees when a dependent system is unavailable. Decide whether the order should be stopped, saved or accepted with a clear reservation.

Product information enriched in PIM should be distributable to the website and portals with the same item identity. At the same time, each channel needs to be able to show the right range and the right permissions.

A working interface is therefore only the start of testing. Also check how the order department spots a rejected message and how the customer is informed. That chain decides whether a technical error becomes a manageable case or a lost order.

Migrate data in three controlled runs

Underestimated data migration becomes especially troublesome when the business system has to exchange information with the website, PIM and portals. A field can import technically and still end up with the wrong meaning. An item that used to be sold per pack can, for example, be read as a single-unit item.

Start with a system register and a field mapping for items, customers, suppliers, prices, stock, orders and finance. Classify the fields as master data, transaction data, history or derived values. Set owner, format, validation rule and source before the first extract.

Plan three controlled runs: a trial extract, a full test migration and a dress rehearsal. The trial extract tests mapping and data quality. The test migration tests the full data set, while the dress rehearsal also tests timing and sequence.

After each run, the business should check the result with business reports and control totals. A technical message that the import succeeded says nothing about stock value or open orders. Keep the reconciliation so the next run can be compared against the same baseline.

For master data, active items must have a unique key, an approved unit and a valid price relationship. Customer and supplier registers must be free of duplicates and have valid identities and the right permissions. Check that customer-specific prices, discounts and VAT codes match the source.

For transaction data, stock levels must match between source and target after every run, and open orders and partial deliveries must carry over without duplicates. Finance requires a signed reconciliation against reports in both systems. History must have understandable context in the target system or be covered by a documented archiving decision.

Set the tolerances before testing starts. Active items must have unambiguous keys and valid units. Differences in orders and stock need to be explainable by documented rules, for example an agreed way of handling closed records.

Then test deliberate errors. Send the same order again, delay a message and change a record while the transfer is running. Require the integration to retry without creating duplicate business events, which is what idempotency means.

Fix the master record where the data is owned. A temporary fix in the import file needs to be documented and fed back, otherwise the error returns in the next run.

Common checkpoints are duplicates, differing item numbers, missing units, incorrect VAT codes and history with no understandable link to the transaction. Older data sometimes needs to be archived with searchable access. The decision should state who needs the data and how it will be found.

Parallel running needs an end condition. The Swedish National Audit Office's report on strategic digitalisation projects describes projects where remaining parallel systems increased licence and operating costs. So plan the decommissioning as soon as the temporary solution is approved.

Test the launch and be prepared to stop

During the rehearsal night, the team should follow a runbook that is already written. Each activity needs an owner, a start condition and a verifiable result. New migration scripts during the actual go-live make it hard to know what has really been tested.

Before the switch, finance needs to decide which periods should be closed. Master data is frozen according to agreed rules, and the channels are told when the old order flows stop. Customer service needs to be able to explain any limitations to customers.

Before the freeze, finance and the information owners reconcile periods, master data and the last regular transfer. During the switch, the migration lead makes sure stock and open orders are loaded in the agreed sequence. When the integrations start, the integration lead follows a known test order through the whole chain. Before opening, the process owners sign off the reconciliation of finance, stock and orders. After opening, the person responsible for ongoing management monitors error queues, customer cases and usage.

Use test orders that reflect your hardest everyday cases. Include a customer-specific price, a partial delivery, a credit and an EDI order if you use that channel. Check both the result in the business system and the message to the customer.

The rollback plan needs to cover business events that have already left the systems. An order may have been sent to the warehouse or confirmed to a customer. State how these events are identified and who decides whether they should be completed or reversed.

Do not open the channels while the team is still discussing who owns a critical discrepancy.

This approach requires process owners who can set aside time. Someone needs to own master data, and someone must be able to stop the launch even when suppliers and internal teams are booked. Management needs to protect that time from regular duties.

A simultaneous group-wide launch is a poor fit when the companies use different item identities or lack shared approval requirements. A limited pilot then gives a better chance to test the sequence of work. It also requires a plan for exchanging information between the old and new solution.

After opening, ongoing management needs to follow the actual work. Check whether users work in the new flow or fall back on their own files. Link every recurring workaround to an owner who can change the way of working or fix the function.

Lock in integration responsibility before you sign

The contract is really tested when the systems start being upgraded at different paces. The business system can change an interface while the website and PIM stay on earlier versions. Your review of responsibility for integrations with the business system therefore needs to cover the whole period after launch.

Ask who owns the integrations when the systems are upgraded at different paces. Ask for a named role, a test sequence and a route for reporting faults. The answer shows whether anyone is responsible for the whole information flow once the implementation project has ended.

Ask for the division of responsibility, the test plan, the contract scope and a list of customisations, so you can judge who coordinates troubleshooting, which flows are tested before an upgrade, what triggers extra charges and which dependencies need to be handled separately.

Follow up by asking how a new version is tested against orders, prices and stock, and whether that testing is included in the contract. A useful answer describes the test environment, sample orders and approvers. It shows whether ongoing management is budgeted and whether the business needs to book its own time.

Also ask the supplier to describe how a failed test is handled. You need to know whether the upgrade is postponed, how the error is prioritised and who coordinates the parties involved. A general promise of compatibility gives too little support when schedules clash.

A clear contract describes both who fixes the error and who holds the work together until the flow is working again.

Finish by asking what happens to your customisations during an upgrade and whether they are isolated from other functions. The answer shows how much work comes with every new version. Ask for dependencies and limitations to be documented before you place the order.

A replacement can reach go-live and still leave behind an expensive version dependency. That is why you need to judge how the solution can be changed once the contract is signed. That judgement needs concrete examples from your own order chain.

A clearly scoped assessment gives you the cost picture before you decide

A decision basis needs to separate the new business system from the changes in your digital channels. The cost depends on which functions can be kept, which connections change and how responsibility is shared. For a useful comparison, suppliers need to price the same scope, otherwise you are comparing three different projects.

At Glanser, we take long-term product ownership of websites, product websites, PIM and portals. Our solutions are built from the Function Library, where every function is already built, tested and priced before work starts. Functions come at three levels: Standard is used as it is, Adapted is configured to your business logic and Customer-unique is isolated so it does not affect the rest during upgrades.

For Litium and Business Central, there is a ready-built connector in the Function Library. The scope still needs to be checked against your pricing rules and exceptions, and that is where the cost picture can differ between customers.

Glanser Care is a contracted responsibility at a fixed monthly cost covering version tracking, compatibility through upgrades, maintenance of the integrations with the business system and bug fixing. Upgrades do not require a new quote.

Our approach requires you to appoint a process owner for the integrations. Your business rules and priorities still need to be decided by you.

If you want to build your own development capability and own every technical choice yourselves, a different approach may suit you better. The same applies when most of your needs call for standalone custom development. The fit should be tested before you commit to a delivery model.

Include internal working time in the budget. In the walkthrough of three items missing from your TCO calculation, the reserve and the work after implementation belong in the same picture. For your connections to the business system, the decision basis needs to cover both implementation and ongoing responsibility.