Summary: Domestic-stack private deployment involves more than an operating system: CPU architecture, database, middleware, browser, and third-party components also matter. For dashboards, BI, software, and digital twins, a workable approach is to lock the target environment and versions, build a dependency matrix, test a minimal viable path, then run migration regression, performance, and permission tests while retaining installation, test, issue, and rollback evidence.
Project note: Judge domestic-stack compatibility against a named and versioned target environment, repeatable test steps, and reviewable evidence. Keep untested components marked “To verify” until testing supports a conclusion.
Projects may use terms such as domestic-stack adaptation, Xinchuang compatibility, domestic hardware and software, private deployment, or internal-network deployment together. They are not identical acceptance targets. Private deployment means the system runs on infrastructure and networks controlled by the client. Domestic-stack adaptation also requires specific products, versions, CPU architectures, replacement scope, and compatibility requirements.
| Requirement wording | Clarify | Acceptable output |
|---|---|---|
| Supports a domestic operating system | Product, version, CPU architecture, desktop or server edition | Installation record, service status, core-workflow regression, and resource use |
| Supports a domestic database | Database product, version, deployment mode, data volume, and migration window | Schema migration, data reconciliation, SQL regression, performance, backup and recovery records |
| Supports a domestic browser or endpoint | Browser engine, version, GPU, resolution, and security policy | Page, chart, WebGL, video, export and print, and sustained-operation tests |
| Passed Xinchuang acceptance | Acceptance basis, product catalog, assessor, evidence format, and responsible party | The project-agreed test report; certification or formal assessment must come from an authorized party |
Record at least server CPU architecture, OS distribution and patches, database product and version, middleware or runtime, reverse proxy, container platform, browser and endpoint, GPU driver, internal domain certificate, authentication, audit logs, backup platform, and external APIs. If the project specifies products such as Kylin, UnionTech UOS, Dameng, Kingbase, or Highgo, still confirm exact versions and deployment modes.
If the final environment is unavailable, build an equivalent test environment and note every difference. Differences in CPU architecture, kernel, browser policy, database version, or security component may make earlier test results inapplicable.
| Module | Common risk | Suggested test |
|---|---|---|
| CPU and operating system | Wrong binary architecture, missing system libraries, permission or path differences | Installation and startup, service autostart, directory rights, time zone, and resource limits |
| Database | SQL dialect, field types, functions, case sensitivity, pagination, and driver differences | Schema migration, critical SQL, batch processing, indexes, transactions, and reconciliation |
| Middleware and runtime | JDK, Node, container-image, messaging, and cache versions do not match | Build, startup, connection, exception recovery, and upgrade rollback |
| Browser and display endpoint | Missing fonts, WebGL support, video codec, scaling, and security policy | Main pages, interactions, exports, printing, fullscreen, and long-running operation |
| GIS and digital twin | Map services, offline tiles, coordinate systems, model loading, and GPU performance | Realistic data coverage, representative models, point interactions, and weak-network recovery |
| Identity and security | Incomplete single sign-on, LDAP, domestic cryptography certificates, permission filters, or audits | Login and logout, timeout, negative authorization tests, log retrieval, and certificate renewal |
| Third-party services | Maps, messaging, storage, printer controls, or commercial components cannot be replaced | License checks, network access, alternatives, and failure handling |
Prototype tests should target the issues most likely to change the approach: database drivers and critical SQL, ARM binary dependencies, browser WebGL and video, single sign-on, offline maps, file export, and fonts. After those pass, plan full data migration, feature regression, performance, and launch windows.
Beyond table and record counts, check field types, defaults, primary keys and sequences, time zones, nulls, character sets, precision, stored procedures, triggers, views, indexes, and permissions. Rerun creation, updates, queries, pagination, aggregations, batch operations, and exports in the app. Reconcile critical reports with the same filters.
Performance testing needs realistic data volume, concurrency, network, and hardware. Queries working on development samples do not prove large aggregations, map points, or scheduled jobs will meet targets in production.
These systems are especially sensitive to browser engines, GPU drivers, WebGL, fonts, resolution, scaling, video codecs, and long-running operation. Do not accept them only on a developer's laptop. On the actual large-screen controller, office workstation, or staffed terminal, test first load, transitions, interactions, fullscreen, outages, reconnection, sustained runtime, and resource use.
For map tiles, geocoding, 3D engines, and commercial controls, also check internal-network deployment, licensing, offline resource updates, and alternatives. Without internet access, prepare local assets and an update process.
At a minimum, the migration plan states downtime window, incremental-data handling, checkpoints, business approver, backup location, rollback trigger, and rollback owner. “Keep the old server” is not a complete rollback plan. Verify that the old system can take traffic again, how new data will be reconciled, and how duplicate writes or losses will be prevented during switching.
Keep installation logs, version screenshots, configuration baselines, test cases, data reconciliation, performance results, issue closure, backup and recovery, and rollback exercises in one evidence set linked to each checklist row.
| Conclusion | Meaning | Evidence needed |
|---|---|---|
| Verified | Tested in the agreed versions and representative environment against acceptance criteria | Environment baseline, steps, results, logs or screenshots, and approver |
| Conditional pass | Works only with specified configuration, patches, replacement components, or constraints | Constraint notes, configuration requirements, remaining risks, and retest records |
| To verify | Target environment, data, permissions, or test conditions are missing | Outstanding conditions, owner, and planned test date |
| Not compatible | The current path cannot meet requirements and needs replacement or scope changes | Failure, cause, impact, and alternative |
Usually not. Check CPU architecture, database and driver, middleware, browser, fonts and export, mapping and 3D components, authentication, audit logs, backups and recovery, and third-party licenses.
Avoid a firm commitment before products, versions, CPU architecture, deployment mode, and target endpoint are known. List risks and tests first, then issue a compatibility conclusion after testing.
Not necessarily. Check SQL dialect, field types, case sensitivity, time handling, pagination and functions, driver pools, stored procedures, indexes, migration reconciliation, and performance differences.
On the actual browser, GPU, and resolution, test WebGL, fonts, charts, video, map tiles, 3D models, exports and printing, sustained runtime, and outage recovery.
No. It organizes project scope, compatibility tests, and acceptance evidence; it does not replace vendor compatibility certificates, assessment reports, procurement catalogs, or decisions by competent authorities.
Use the Xinchuang and Domestic Private-Deployment Compatibility Checklist (Chinese) to record environments, adaptation requirements, test methods, risks, conclusions, and evidence. Continue with What to Prepare for Private Deployment of a Data Dashboard, How to Agree on Software Project Changes and Source-Code Handover, and How to Maintain a Data Dashboard After Launch.