Contentrain
Migration playbook

Migrate hardcoded strings into governed content

A migration path for extracting AI-generated UI copy, labels, empty states, and page text from source files into structured Contentrain content.

See Normalize

Audience

Developers cleaning up AI-built apps, agencies modernizing client sites, and teams preparing for localization.

Outcome

Hardcoded strings become structured, reviewable, localizable content without a risky rewrite.

Operating model

What the workflow needs to prove

Discovery

Scan before you model

Do not guess the content model first. Scan source files, inspect candidate strings, and group content by how the product will edit and translate it.

  • Candidate mode
  • Graph mode
  • Source tracking

Extraction

Write content before touching source code

Normalize separates extraction from reuse. Approved strings become content entries first, then source patches follow after review.

  • Content entries with source traceability
  • No source mutation during extract
  • Reviewable generated content

Reuse

Patch code to consume generated content

After content is ready, replace hardcoded strings with generated SDK access. This makes future edits content operations instead of source changes.

  • Framework-aware expressions
  • Import insertion
  • Conflict checks

Implementation steps

Run the workflow in this order

1

Run a scan summary

Estimate the amount and location of hardcoded strings.

contentrain scan --mode summary
2

Review candidates

Choose strings that are product content, not implementation details.

3

Extract approved strings

Save entries into dictionaries, pages, or collections through Contentrain.

4

Generate client access

Regenerate the query client after content changes.

contentrain generate
5

Apply reuse patches

Patch source files only after the content shape is validated.

Checklist

Quality gates before handoff

Do extract

  • Navigation labels
  • CTA copy
  • Empty states
  • Validation messages
  • Landing page sections

Do not extract blindly

  • Debug strings
  • Internal constants
  • Class names
  • Test-only fixtures

Validate outcome

  • No broken imports
  • No missing locale fields
  • Page content still fits UI containers

Common questions

Should every string become content?

No. Extract product-facing text that humans will edit, translate, review, or reuse.

Why split extract and reuse?

It makes the migration reviewable and avoids changing content and source code in one opaque step.

Can this support localization?

Yes. Once strings are structured content, locale parity and translation review become normal content workflows.

Next paths

Continue through the content system

Developer implementation playbook

Install, model, validate, generate, and ship runtime access.

Hardcoded strings use case

Why string extraction matters.

Content editor workflow playbook

Give editors Studio workflows without losing Git review.

Start local. Scale to Studio.

Build a governed content layer before content becomes product debt.

Developers can start with the MIT packages. Teams can move into Studio when review, roles, delivery, and licensing matter.

Open Studio