<p>Strapi did its job on Terry Hunt Dev. It gave me structured content, an admin panel, and a clean API for Next.js. I began moving the site on an Amplify Gen 2 migration branch because I wanted to learn through a real application instead of another todo demo. The branch now contains a TypeScript backend definition, AppSync data access, and Cognito-backed administration. The repository still lists production schema deployment and hosted admin CRUD verification as remaining work, so this is a migration-in-progress case study rather than proof of a completed production cutover.</p>

<h2>What I was giving up</h2>

<p>The existing CMS already handled the work I would otherwise have to rebuild. I could define collection types, reusable components, relations, media fields, and editorial permissions without building each screen myself. The <a href="https://docs.strapi.io/cms/features/content-type-builder" rel="noopener noreferrer">Strapi Content-type Builder documentation</a> shows the same content-modeling tools that made the original backend practical.</p><p>Draft &amp; Publish was useful because an editor could save work without exposing it on the public site. Strapi still documents that workflow in its <a href="https://docs.strapi.io/cms/features/draft-and-publish" rel="noopener noreferrer">Strapi Draft &amp; Publish documentation</a>. I did not leave because the CMS failed or because I thought it had become obsolete.</p>

<h2>I wanted the learning project to be real</h2>

<p>Small tutorials hide the decisions that make backend work difficult. The Strapi seed importer covers blog posts, projects, landing pages, location pages, services, and SEO overrides. The Amplify schema also contains <code>SiteSettings</code>, <code>MarketingCampaign</code>, <code>SeoPage</code>, and <code>Contact</code> models, but those four are populated through separate workflows rather than this Strapi importer. Working through the imported collections forced me to handle authorization, publishing state, stable URLs, and failed imports.</p><p>Amplify Gen 2 defines backend resources in TypeScript. The <a href="https://docs.amplify.aws/nextjs/build-a-backend/data/set-up-data/" rel="noopener noreferrer">Amplify Data setup guide</a> covers schema definition, generated clients, and authorization rules. I wanted experience with that model and the AWS services behind it, so I used my own site as the test case.</p>

<h2>I mapped the content before changing the API</h2>

<p>I started with a field inventory rather than translating Strapi responses inside page components. Each Strapi collection mapped to an Amplify model or a deliberate consolidation. Slugs, canonical URLs, publication dates, robots directives, SEO fields, and structured data needed explicit destinations.</p><p>Relations and components forced a choice between normalized Amplify models and JSON stored as one page section. I used JSON when the frontend consumes the structure as one array. Frequently queried fields such as blog slugs and categories became secondary indexes. This was a new data model built from the old editorial requirements, not a mechanical rename.</p>

<h2>The Amplify schema became part of the repository</h2>

<p>The current <code>amplify/data/resource.ts</code> defines ten models, including <code>BlogPost</code>, <code>Project</code>, <code>LandingPage</code>, and <code>Contact</code>. Public content models allow API-key reads while the Admin Cognito group controls writes. Contact records use a narrower rule because public visitors should not read submissions.</p><p>Keeping the schema beside the application made backend changes visible in code review. It also meant I had to design the admin experience, publication rules, and field validation that Strapi had supplied through its CMS interface.</p>

<h2>I used an importer I could run more than once</h2>

<p>The migration script reads the exported Strapi seed data, maps each record, and sends GraphQL mutations to Amplify Data. Stable IDs based on slugs let the script find existing records. By default it creates missing records and skips existing ones; an authenticated Admin token is required when I intentionally update data.</p><p>I kept the transformations explicit. Arrays are coerced to string arrays, selected media objects are reduced to URL or path values, and JSON values are serialized for AppSync JSON inputs. Missing publication dates receive a current ISO timestamp, but existing date strings pass through unchanged. Strapi also provides official <a href="https://docs.strapi.io/cms/features/data-management/transfer" rel="noopener noreferrer">Strapi data transfer documentation</a>, but a cross-platform move still needs a field map because the destination schema and authorization model differ.</p>

<h2>The frontend moved after the data</h2>

<p>The repository's public data loaders now use Amplify and AppSync, and the importer uses slug-derived IDs while logging created, updated, and skipped totals for each collection. The repository does not retain a complete source-versus-destination reconciliation report, so I do not claim count parity from code alone. It also includes custom <code>/admin</code> routes for Admin-group Cognito users, although the deployment checklist still marks hosted CRUD verification incomplete.</p><p>I check rendered pages as well as API responses because titles, canonicals, robots directives, images, structured data, sitemaps, and draft visibility can regress while a record looks correct in GraphQL. Tracked records from <code>content/blog-drafts</code> import as <code>draft</code> and <code>noindex,follow</code>. Other imported records use their source <code>publishStatus</code>, and several mappers default a missing value to <code>published</code>, so pending editorial state must be explicit in the source data. The current public API-key read rule does not make drafts private; the rendered site filters unpublished records, and drafts cannot contain nonpublic material until the API boundary enforces that distinction.</p>

<h2>The migration moved CMS work into my codebase</h2>

<p>Amplify Gen 2 brought the backend definition, authorization rules, and deployment configuration into the same TypeScript project as the site. That was the learning goal. I now configure AppSync access, Cognito groups, generated outputs, branch environments, and request permissions directly.</p><p>Strapi remains the stronger fit when a team wants its ready-made content manager, media library, plugin options, and editorial workflow. My Amplify version uses a custom admin and repository-specific import tools. Those are useful for this application, but they are code I must maintain.</p>

<h2>I kept the old bridge during verification</h2>

<p>The repository still names the temporary import command <code>import:strapi-seed</code>, and a few runtime error classes retain Strapi-oriented names. I left those clues in place while verification and cleanup continued. Removing the bridge too early would make a missed record harder to recover.</p><p>The final cleanup includes rotating old Strapi tokens, deleting obsolete secrets, renaming migration-only code, and preserving a separate export for audit and rollback. My <a href="/blog/strapi-cloud-vs-self-hosting">Strapi hosting guide</a> covers the operating model I left, while <a href="/blog/aws-amplify-vs-vercel-nextjs">Amplify vs. Vercel for Next.js</a> explains the hosting tradeoffs around the new stack.</p>

<h2>Choosing between Strapi and Amplify Gen 2?</h2>

<p>I still recommend Strapi when a project needs a mature editor-first CMS. For an AWS-centered application, I can help map the content and authorization requirements before any data moves. Share a sanitized model inventory through the <a href="/contact">contact page</a>, or see how I work with <a href="/services/strapi-development">Strapi</a> and <a href="/services/aws-development">AWS</a>.</p>

See how I am moving Terry Hunt Dev from Strapi to AWS Amplify Gen 2 by redesigning its schema, importing seed collections, and testing the migration branch.

My Strapi to AWS Amplify Gen 2 Migration

Strapi was a good CMS for Terry Hunt Dev. I began moving the backend to Amplify Gen 2 because I wanted to learn a different way to model, secure, and deploy application data.

Moving from Strapi to AWS Amplify Gen 2 to Learn a New Backend

<p>I treat a content migration as a data project with a visible acceptance report. The source may be an older CMS, spreadsheet, database export, or files. Each source has missing values and conventions that should not become permanent Strapi fields without review.</p><p>I import into drafts first. Editors can compare records and rendered previews before anything becomes public.</p>

<h2>Inventory the source</h2>

<p>I count records by type and collect field names, formats, relations, media references, publication state, and URLs. I mark fields that contain HTML, embedded shortcodes, or mixed meanings. A sample of unusual records matters more than one perfect row.</p><p>The inventory includes current redirects and indexed URLs. A content move that preserves text but loses canonical paths can damage search and inbound links.</p>

<h2>Create a written field map</h2>

<p>Each source field maps to a Strapi field, transformation, default, or deliberate discard. I distinguish empty from unknown and record who approves defaults. Relations use stable source identifiers rather than titles that may repeat.</p><p>I create components only after finding a repeated structure. Parsing arbitrary HTML into a rigid component without enough evidence creates manual repair work.</p>

<h2>Normalize before import</h2>

<p>I normalize whitespace, dates, slugs, booleans, enum values, and URLs in a staging dataset. Duplicate slugs and malformed dates stop the run. I preserve the original source ID in a migration-only field or mapping file for reconciliation.</p><p>Media filenames receive safe names and alt text remains separate from captions. Missing alt text enters an editorial queue instead of being invented.</p>

<h2>Import drafts in dependency order</h2>

<p>I create independent records before records that reference them: authors and categories, then articles, then relation links. Media uploads happen through the configured provider and their returned identifiers feed the content import.</p><p>The importer is idempotent. Re-running a batch updates the mapped draft or skips it rather than creating duplicates.</p>

<h2>Compare data and rendered pages</h2>

<p>I compare source and destination counts, required-field failures, relation counts, missing media, duplicate slugs, metadata, and internal links. Then I render representative pages in Next.js and inspect headings, tables, code blocks, canonical tags, and schema.</p><p>Automated counts find broad gaps. Editorial sampling finds damaged meaning and poor formatting.</p>

<h2>Publish in a controlled batch</h2>

<p>I back up Strapi, publish a small approved batch, apply redirects, and crawl the public routes. The report records HTTP status, canonical, robots state, and missing links before the next batch proceeds.</p><ul><li>Source counts are recorded.</li><li>Every field has a mapping.</li><li>Imports are idempotent.</li><li>Drafts receive editorial review.</li><li>Redirects and rendered pages are tested.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev handles CMS architecture and migrations through <a href="/services/strapi-development">Strapi development</a> and <a href="/services/technical-seo">technical SEO</a>. Request a migration assessment through the <a href="/contact">contact page</a> with a field list, not private records.</p>

Use this Strapi content migration checklist to map fields, normalize slugs, import drafts, connect media and relations, and verify counts and rendered pages.

My Checklist for Migrating Content into Strapi

Inventory, normalize, import, and verify content in Strapi without losing relations, media, redirects, or metadata.

Content Migration Resources & Benchmarks

Moving from Strapi to AWS Amplify Gen 2 to Learn a New Backend

My Checklist for Migrating Content into Strapi

Need hands-on help with Content Migration?