Znode 9 to 10 migration: give every customization a plan.

Preserve the reason the customization exists.

An account selector might look like a small control, but it can determine catalogs, prices, addresses, payment options, and the active cart. A custom order service may also carry customer identifiers, units, tax decisions, and recovery rules. The important migration requirement is the behavior that these pieces support.

Inventory each customization with its users, inputs, outputs, permissions, external dependencies, and side effects. Ask what should stay, what the target release can provide through configuration, and what is no longer needed. This gives the business a say before engineering commits to rebuilding familiar code.

Make the runtime and extension changes explicit.

Znode 9 uses .NET Framework 4.8 in the legacy application stack discussed in GCG's guides. Znode 10 uses ASP.NET Core and modern .NET for Custom API development, with a React and Next.js storefront and Page Builder development model. The exact SDK and package versions should be recorded for the target release.

That distinction affects application lifecycle, dependency registration, storefront composition, deployment, and extension boundaries. A Razor or jQuery customization needs an intentional frontend design. A legacy service override needs a supported target extension. Treat those as engineering decisions rather than a series of syntax substitutions.

Choose a home for the data and the rules.

Separate Znode-owned entities from project-owned information and external-system records. A supported entity attribute may be enough for a value owned by an account or product. Small reference data may fit a supported custom-table capability. Relational project data may need its own database and authenticated API.

For a Znode-hosted target, plan to access Znode-owned data through the supported APIs and clients. Keep project database access behind server-side services. A browser, storefront component, or Page Builder widget should receive a defined contract, with authorization enforced at the server boundary.

Review one complete slice before expanding.

Choose a small but representative workflow that crosses the important boundaries. An account-specific purchase can exercise identity, account selection, catalog access, pricing, quantity rules, and the order handoff. Define expected results with sanitized examples that can be compared across implementations.

Plan the sequence around data readiness, integrations, configuration, storefront behavior, and operational procedures. Include logging, reconciliation, and a recovery route for exceptions. Keep rollback responsibilities and any data-transition constraints explicit so a release decision is based on the complete workflow.

Build the migration brief around decisions.

A useful roadmap states what the business will gain, which current behaviors remain necessary, and how the target architecture supports them. It should also identify the work needed to keep the existing environment dependable during the transition.

1. Record the current Znode patch, application surfaces, jobs, integrations, and custom data stores.
2. Map each customization to the business behavior and permissions it must preserve.
3. Agree retain, rebuild, or retire decisions with the responsible business owners.
4. Record the target SDK, hosting model, supported extension, and data owner for each retained behavior.
5. Define representative acceptance scenarios, transition dependencies, and operational recovery responsibilities.

Go deeper into the implementation.

Follow the version-specific technical guides and complete recipes behind these planning decisions.