Three Practical Suggestions for Enterprise IT Procurement Under Domestic Substitution

Hold off on the purchase order: the policy window is narrower than you think

Last week, after we finished an IT audit for an auto parts manufacturer in Shunyi, the owner’s first words were, “We’d rather wait until domestically developed IT products mature before switching.” By “wait” he meant two years; I told him that adaptation and validation of core systems needs to be completed by the end of this year. Domestic substitution is not a multiple-choice question — it’s a countdown. The goal of full completion across Party and government agencies by 2027 was set long ago, and while there is no mandatory requirement for enterprises yet, leading customers have already begun treating domestic-innovation (xinchuang) qualifications as an entry threshold in tenders. Your suppliers, your system architecture, your data compliance approach — all of these take time to refine. The smartest approach I’ve seen: pilot with a non-core business system first — office collaboration or an internal approval workflow, for example — and use 3–6 months of real operating data to judge migration costs, rather than deciding based on a vendor’s slide deck.

Designing the migration path: phased, not a one-time cutover

Last year we built a full migration plan for a food processing company. They were running Windows Server 2012 with SQL Server, and the database held 8 years of production and operating data. Their vendor quoted a “one-click migration” solution that sounded wonderful. When I got on site, I found the so-called migration tool could not handle their legacy data formats at all; in the end it still came down to manual data cleaning. The company’s IT manager told me, “We really should have tested the waters with a peripheral system first.” There is a basic principle for migration path design: easy before hard, data before applications, peripheral before core. Map out your business systems by their dependencies, and migrate first the ones with few external interfaces, simple data structures, and friendly downtime windows. For general-purpose systems such as OA, email, and access control, domestic alternatives are already very mature and the risk of compatibility problems is low. But for systems deeply tied to the production line, such as ERP and MES, put them in the second or even third batch. For migration pacing, I recommend this sequence:

1. Phase 1 (1–2 months): complete the current-state assessment and risk evaluation, and lock in the 3–5 highest-priority systems
2. Phase 2 (3–6 months): select one non-core system for a complete migration validation and establish a standard process
3. Phase 3 (6–18 months): migrate the remaining systems in batches using the validated process, completing staff training in parallel
4. Phase 4 (after 18 months): move into the operations optimization stage, testing for performance bottlenecks and long-term stability

Vendor audits: don’t be dazzled by certificates

Domestic-innovation qualifications are now standard issue for vendors, but holding one does not mean the product actually works. Last year I audited a database vendor: their domestic-innovation certificate was perfectly in order, yet the product documentation still contained Windows 98 screenshots. What does that tell you? Either the R&D team never took adaptation seriously, or the product’s underlying architecture is still the old approach. Once the procurement contract is signed, you are the one who swallows the bitter fruit of downstream operations. There are several key verification points a vendor audit must not skip. First, actual deployment cases: ask for rollout records from companies in the same industry and of a similar size, and ideally get in touch with real users to ask about their experience. Second, technical support capability: send them a technical question and see whether the response takes four hours or two days — this directly determines the size of your losses when something goes wrong. Third, the authenticity of R&D investment: check their patent count, the share of R&D staff, and the frequency of version releases. R&D investment below the industry average means the product will fall behind sooner or later. If you are evaluating an IT operations service provider, take a look at Siwenlide’s services page — we have both the capability to implement domestic-substitution migrations and the long-term operations support to keep them running afterward. After all, switching systems is only the first step; keeping them running reliably is the real skill. On the subject of procurement risk, there is also a timing issue to watch. We are in the early stage of domestic substitution, and product prices are still inflated. Once the market matures over another 18–24 months, prices for comparable products may fall by more than 30%. Unless policy pressure has left your business systems with no choice but to switch, consider using virtualization or containerization as an interim step and wait until the ecosystem is more stable before making your move. Finally, a word on personnel risk. Domestic substitution is not only an IT systems issue; it also involves a capability shift for your operations team. Can your engineers use Kylin OS? Can they tune a DM (DaMeng) database? Can they handle low-level faults on domestic CPUs? These skills do not come bundled free with the equipment you buy. Set aside a separate training budget — at least 10%–15% of the total investment.