Replacing a business system: how to test monthly and annual processes

Before replacing a business system, test the work that happens at month end, year end and exceptional dates. Creating a customer and entering an order does not prove that periodic calculations, subscription renewals or retrospective corrections will work. Ask the software team for a business calendar, test inputs and an expected result for each scenario. A migration decision should rest on evidence for important processes and a plan for unresolved differences, rather than a demonstration of an ordinary working day.

What can a holiday-pay incident teach a software buyer?

In March 2024, Retail Gazette reported a payroll problem at Asda. According to the company statement quoted in the report, around 9,500 hourly employees were affected by an incorrect holiday calculation during the move to new systems. Asda said preliminary checks had identified the problem and it was taking corrective action; the union reported that some employees were still underpaid. This is a historical report containing different accounts, not our own investigation.

The article does not establish that the team omitted a particular test. Our proposed lesson for software buyers is narrower: a process that looks peripheral during a demonstration may be critical on payment day. Ask which processes have not yet reached their scheduled execution date during the trial. You do not need to wait a year to investigate an annual calculation, but you do need inputs and conditions that represent that point in time.

Build a business calendar before a test list

Start with the people who actually perform the work: operations, support, finance and system administrators. Walk through a representative month and year, asking which actions happen on a fixed date, after an event or only in an exceptional situation. Do not limit the discussion to existing screens. An external report or a manual spreadsheet correction may reveal a business rule missing from the requirements document but still necessary in the replacement system.

For each action, record an owner, timing, required information, expected outcome and potential harm if it fails. In a hypothetical subscription example, decide what happens when a price changes during the billing period or the customer cancels one day before renewal. This is a suggested specification exercise, not a client project we claim to have delivered. Include these rules in the technology product specification, allowing the supplier to estimate and test the actual work.

Choose examples that exercise the rule

A useful scenario includes input records, a point in time and an expected result that an authorised business owner can explain. Cover a normal case, a period boundary, missing information and a correction after closing. Add currencies or time zones when they matter to your process. An enormous exception list that nobody can approve is less useful than a small set covering distinct, understandable decisions.

Run examples in an isolated test environment with synthetic data or information prepared for that use. Ask the team to demonstrate how it simulates a future date without changing the production system clock or triggering real charges, messages or transfers. Where an external provider is involved, record what was exercised against its test environment and what was only simulated. Otherwise, a passing result can conceal a dependency that has never actually been tested.

Compare business outcomes, not just totals

When comparing old and new systems, define which results should remain identical and which are deliberately changing. A matching grand total is insufficient: an incorrect charge to one customer can offset an incorrect credit to another. Compare individual records, calculation explanations and final states as well. Do not assume the old system is always correct. Sometimes the migration is intended to correct an old rule, and the difference needs an explanation and approval.

A test record should identify the software version, sample inputs, expected result, actual result and business approver. When a discrepancy appears, classify it as a defect, a missing rule or an agreed change. This avoids a later dispute in which the development team considers the work complete while operations still cannot close a period. On the next run, repeat both the corrected case and nearby scenarios that the change could affect.

A documented example from Julius's own tooling

Our website publishing tool explicitly checks for valid dates, rejects future publication dates and checks the ordering of publication and update dates. It determines the current day using Israel's time zone. These are rules visible in the tool's code; they are not evidence that we tested a payroll system or migrated a financial platform. The example illustrates why even an apparently simple action needs a precise definition of time and permitted state.

For a system migration, the practical application is to ask the supplier to show the rule and its boundaries instead of merely saying that the system supports dates. If the product includes a model-generated decision, separate deterministic calculation tests from model-output evaluation. Our guide to choosing AI developers discusses quality and failure definitions; a model does not replace a business decision about the correct outcome.

When can the migration be approved?

Agree in advance which scenarios block launch and which gaps can be managed temporarily with a named owner and correction date. Before the transition, check that a usable backup, a recovery path and a plan for records created during the migration exist. Afterward, follow the first periodic close as well as launch day. If evidence for a critical process is still missing, state that explicitly in the decision and reduce the scope or postpone that part.

When speaking with Julius about software development, bring one routine process and one periodic process that is difficult to explain. Request a proposal separating development, data migration, acceptance testing and support for the first close. This makes it possible to compare offers against the work actually required and identify who remains responsible when the system performs a task it has not performed since launch.