Migration, Cloning & Architecture

The customer needed to copy content types and entry content from one stack to another and asked for the recommended approach to migrate content between stacks.

Root Cause

The supported approach is CLI stack-to-stack migration: export content from the source stack, then import it into the target stack. The customer needed confirmation of that pattern and a pointer to the canonical procedure rather than ad-hoc duplication of steps in the ticket.

Resolution

• Explain at a high level that migration is handled with the Contentstack CLI export → import flow (with audit called out in the doc where relevant).
• Redirect the customer to the Migrate content between stacks using the CLI documentation for prerequisites, exact commands, and FAQs.

The target stack shows the expected content types and entries, and the customer confirms the migration matches what the guide describes for their scenario.

After cloning a stack using CLI export/import, the customer observed that entry version numbers in the cloned stack did not match those in the original stack.

Root Cause

Export/import recreates content in the target stack; internal identifiers and version counters often differ from the source. That is expected when treating export/import as a copy workflow, not a byte-for-byte clone of all platform metadata.

Resolution

1. Clarify that:
   • export import recreates entries
   • Original entry version history / sequencing is not guaranteed to match
2. When stack-level cloning with richer parity is required, recommend csdx cm:stacks:clone (and validate the outcome in a non-production stack first).
3. Do not promise identical version numbers unless verified for that customer’s workflow and CLI version.

The customer needed to migrate entries with three-level nested references (e.g., Questionnaire → Question Bundle → Question) from one stack to another.

Root Cause

Stack-to-stack moves with deep reference graphs usually require ordered export/import (parents before children) and/or multiple passes; the CLI does not offer a single “migrate entire nested graph with one flag” for arbitrary models. Roadmap statements belong in product documentation, not as a fixed KB claim—point customers to current docs or PM for feature status.

Resolution

1. Set expectations: plan dependency order and validation, not one-click full automation for arbitrary depths.
2. Manually export:
   • Referenced content types
   • All referenced entries
3. Import them into the target stack in correct dependency order.
4. Revalidate reference relationships after import.

Referenced entries must be manually validated in the target stack to ensure:

• All referenced entries exist
• Reference fields are correctly populated
• No broken relationships remain

Customers requested clarification on CLI usage while migrating from GCP NA to the EU region.

Root Cause

No CLI error occurred. The case involved clarifying the correct CLI workflow for region-based migration.

Resolution

1. Explain export process from source region stack.
2. Explain import process into target region stack.
3. Confirm proper API keys and region endpoints are used.
4. Ensure region-specific stack credentials are configured correctly before running CLI commands.

Users attempted stack cloning using export/import, but internal references did not function correctly afterward. They also asked whether stack cloning is possible via the Content Management API (CMA).

Root Cause

Export/import may not preserve every reference and linking edge case the way a dedicated clone workflow does; outcomes depend on modules imported and order. CMA does not expose a single “clone entire stack” API comparable to cm:stacks:clone—practical stack copies are usually CLI export/import, clone, or custom automation.

Resolution

1. Clarify that one-shot “clone stack” via CMA alone is not the standard pattern.
2. Recommend csdx cm:stacks:clone when full stack replication is the goal; validate references after any path.

During migration from Production to Development:

• Huge number of assets were duplicated
• Assets were recreated instead of linked

Root Cause

Likely incorrect reference handling configuration during migration. Further investigation required CLI parameters and configuration, but no additional details were provided.

Resolution

1. Request:
   • CLI command used
   • Migration configuration
   • Reference handling flags
2. Validate whether duplication resulted from full asset import instead of linking behavior.

The customer raised a platform capability gap: they wanted declarative, framework-style schema migrations (similar to SQL migration tools) for every content model change, with low operational risk.

Root Cause

Contentstack does not ship a single built-in “schema migration framework” that auto-generates and applies arbitrary model diffs like some SQL tools. Operational migrations still exist: teams use csdx cm:stacks:migration (migration scripts), export/import of modules, CMA/scripts, and environment promotion—plus RTE-focused helpers such as cm:entries:migrate-html-rte where applicable.

Resolution

1. Align expectations: plan migrations; use scripts and staging stacks.
2. Apply safe model-change practices:
   • Plan/document model changes before implementation.
   • Maintain a manual version history of content models (exported JSON / change logs).
   • Prefer creating new fields over renaming existing fields (deprecate old field gradually).
3. For mandatory fields:
   • Plan a population strategy (defaults, editor guidance, or scripted backfill).
4. Use available tooling to reduce risk:
   • csdx cm:stacks:migration for scripted stack changes
   • CLI export/import of content models (backup replication across environments)
   • CMA scripts to apply controlled schema updates and bulk updates to entries
5. Always validate changes in non-production environments before production rollout.

The customer asked whether authors can push content from one stack to another automatically through a workflow stage transition (as part of workflow).

Root Cause

Product behavior (workflows): Contentstack workflows do not support cross-stack content migration as an action tied to stage transitions. Cross-stack transfer is outside workflow capabilities.

Resolution

1. Confirm that workflow actions cannot migrate content between stacks.
2. Recommend supported approaches for stack-to-stack migration:
   • CLI export import utilities (contentstack-export / contentstack-import workflows)
   • Custom scripts (for controlled migration automation if needed)
3. Position this as the standard supported method for cross-stack migration workflows.

After migrating content between branches, the customer reported that assets were not visible on the frontend unless entries were manually republished. This created the impression that publishing was required post-migration for assets to render correctly.

Root Cause

This was not a universal publishing requirement from Contentstack. Based on the case notes, the customer’s workflow assumed that migrated entries must be republished for assets to become available.

Support confirmed that publishing entries was not required for assets to be usable post-migration in their scenario, and provided a workaround to avoid an unnecessary republish cycle.

Resolution

1. Review the customer’s post-migration workflow where entries are being republished purely to “make assets appear.”
2. Apply the workaround shared in the case: proceed without republishing entries, since republish was not required to make assets available in that use case.
3. Ask the customer to repeat their validation steps (asset rendering/use) without republishing, and confirm if the behavior is consistent.

Assets are usable/visible post-migration without requiring manual republishing of entries in the validated case, and the customer is able to proceed with migration activity without the republish step.