A substitution deadline is not a verdict on the software

Since about 2020, a large share of my company's domestic work has come from one kind of instruction. A state-owned group, sometimes a large private one, decides that its core systems will run on domestic databases, operating systems and middleware by a stated date. The date is set at group level, often with reference to wider policy, and it travels down the organisation into the annual assessments of the people who must meet it. Then a tender appears, and firms like mine bid to do the work.

I support the direction of this programme. Chinese enterprises have good reasons not to depend on foreign software whose supply, support and updates can be withdrawn by decisions made elsewhere, and the experience of the past few years has made those reasons concrete. Domestic databases and operating systems have improved faster than many foreign observers assume. On most of the transactional workloads we migrate, they perform as well as the products they replace.

My argument is narrower, and it concerns firms like mine. In a substitution programme the deadline is the most visible measure of success, and the services firm is paid to meet it. That makes us the party most tempted to treat the date as proof that the work is good. It is not, and an integrator that behaves as though it were harms its client, the domestic software it installs and, eventually, itself.

What the deadline buys

A deadline does useful things. It forces a decision that committees would otherwise defer for years, it releases budget, and it gives domestic software makers a volume of real installations that no laboratory could provide. About 45 per cent of Yanxiao's domestic revenue of RMB 1.78 billion in 2025 came from substitution work, and I am not embarrassed by that.

What a deadline cannot do is distinguish between a migration that works and one that has merely been completed. The measure usually reported upward is the share of systems moved, sometimes the share of licences replaced. A system that has been moved and then runs its month-end batch three times more slowly, or rounds tariffs differently, or quietly depends on a foreign component nobody listed, counts the same as one that runs better than before. The people closest to the work usually know the difference. The reporting line that ends at group level usually does not.

In that gap the integrator's incentives are poor. We are paid on milestones tied to the date. Our sales teams are measured on contracts signed. Raising a performance problem late in a project invites a dispute about whose fault it is, and raising it early can lose the tender to a firm that promises not to find one. I have watched competent companies, mine included, choose not to look too hard.

Test on the client's worst day

At Liaoxin Port Group in 2023 we ran a load test on a copy of the port's busiest month-end before agreeing a cut-over plan. The domestic database then available took 6 hours 40 minutes to complete a billing batch that the old system finished in under two hours. Rounding and collation behaviour changed about 0.3 per cent of tariff calculations. None of this was a scandal. It was the normal distance between a product's general capability and one client's peculiar workload, and it could be closed. It could not be closed by the date the group had set.

We told the client in writing, with the test results attached, and proposed migrating forty peripheral applications on time and the billing system after three months of parallel running. We lost RMB 112 million of the contract to a competitor that accepted the original date. With the database supplier's engineers we redesigned the batch, and their next release brought it to 2 hours 10 minutes. Billing moved in September 2024 and produced no disputed invoices in its first month.

From that experience we adopted three practices, and I think every integrator in this market should adopt something like them. First, test on the client's worst day, not on the vendor's demonstration set: the busiest batch, the oldest stored procedures, the reports nobody has documented. Second, give the client a written readiness report before bidding, listing what will not yet run at equal performance and what would have to change. Third, insist on parallel running for anything that bills, pays or settles, and price it openly, so that the client sees its cost rather than discovering it later.

There is a further reason for candour that is easy to miss. Domestic software makers improve fastest when integrators send them precise evidence of where their products fall short. An integrator that hides a performance gap to protect its milestone deprives the supplier of the defect report it most needs. The release that rescued our billing migration came from engineers who had seen our test data. Concealment slows the very products the programme exists to build up.

After the quotas are met

The second part of my argument concerns time. Substitution demand of this intensity will not last indefinitely. As groups meet their dates, the volume of mandated migration will fall, and what remains will be the ordinary work of running, improving and eventually replacing systems. Clients will then choose integrators on whether their migrated systems work, and on whether the people who moved them told the truth while doing so.

A services firm that has grown by accepting every date will meet that change with a book of fragile systems and a reputation to match. I would rather grow more slowly now. Our domestic revenue would probably have been RMB 200 million or so higher over the past three years had we accepted every deadline offered. Our domestic gross margin would also have been lower, and some of that revenue would have come back to us as warranty work.

I should be honest about what this position costs beyond money. Project owners at our clients, whose own assessments depend on the date, do not always welcome a vendor who documents why it cannot be met, and some have not invited us to bid again. Our domestic sales team has lost commissions it would otherwise have earned, and several good salespeople have left for competitors who promise more. There is also a fair criticism that a written readiness report can become a way for a vendor to protect itself rather than to help the client. We try to answer it by proposing a route to the date wherever one exists.

For the directors of enterprises running these programmes, the practical question is simple. Ask management not only what share of systems has moved, but how the moved systems perform on their busiest day compared with before, how many are still running in parallel and why, and which components remain foreign because nobody has yet found them. A board that receives those answers will be measuring substitution as it was meant to be measured: by systems that work on domestic foundations, not by dates that were met.