Building Admin Tools on AWS Amplify During a CMS Migration

Large-scale CMS migrations create a window of operational complexity: the old system is still running, the new system is coming online, and the editorial staff need tools that work in both worlds simultaneously. This is the problem AWS Amplify and a custom React admin application solved during a major news site migration.

The Workflow Gap

The legacy CMS had custom editorial tools that had been built over a decade: bulk content tagging interfaces, SEO audit dashboards, newsletter scheduling tools, and content performance reporting. None of these existed in the new system out of the box.

The decision: build a parallel admin application on AWS Amplify that could read from both the legacy CMS API and the new platform’s API. Editors could use it during the migration period, and it would evolve into the production admin tooling for the new platform.

Why AWS Amplify for This

Amplify provided the authentication layer (Cognito) without building it from scratch, a straightforward hosting and deployment pipeline, and environment-based configuration that let the application point at different APIs in development, staging, and production.

The authentication requirement was non-trivial. Editorial staff had existing corporate SSO. Amplify’s Cognito integration with SAML identity providers handled this cleanly without building a custom auth system.

The React Architecture

The admin application was intentionally separate from the public-facing site’s codebase. Different deployment cadence, different stakeholders, different performance requirements. Editorial tools need to be correct, not optimized for sub-second LCP.

React’s ecosystem richness mattered here: data grid libraries, chart components, drag-and-drop interfaces — all mature and available. The admin surface area was complex enough that React’s component model paid off.

State management was Zustand, not Redux. The state in an editorial admin tool is more isolated than in a consumer product — the bulk tagging interface doesn’t need to know about the newsletter scheduling state. Zustand’s module-per-feature pattern kept the code organized without Redux’s full infrastructure.

Content API Abstraction

The core architectural challenge: querying both the legacy CMS API and the new Arc XP API from the same React application.

The solution: a content service abstraction layer. Both APIs were wrapped in adapters that returned a common data shape. UI components never called APIs directly — they called content service methods.

interface ContentService {
  getArticles(params: ContentQuery): Promise<ArticleListResult>;
  updateArticleTags(id: string, tags: string[]): Promise<void>;
  getPerformanceMetrics(id: string): Promise<ArticleMetrics>;
}

// Two implementations during migration
class LegacyCMSService implements ContentService { ... }
class ArcXPService implements ContentService { ... }

// Toggled by feature flag
const contentService = featureFlag('use-arc') ? new ArcXPService() : new LegacyCMSService();

Feature flags controlled which implementation was active per content type as migration progressed. The UI required zero changes when backends switched.

The Deployment Pattern

Amplify’s hosting connects to a GitHub branch. Every push to main triggers a build and deploy. For editorial tooling where incorrect deployments can disrupt a live newsroom, we added:

• Manual approval step in the production pipeline
• Automatic staging deployment for every PR
• Smoke test script that verified critical editorial workflows after each deployment

The manual approval added 5 minutes to production deployments. It prevented three incidents in the first month where staging-only bugs would have reached production editorial staff.

Lessons From the Migration Window

The migration admin tool was planned as temporary — a bridge tool that would be retired when the new system was fully operational. It survived and became permanent, which taught us a lesson about “temporary” tools in a newsroom.

Build temporary tools with enough quality that they could become permanent. The data model, API abstraction, and authentication patterns we chose in the first week were in production for two years. The technical debt you accept in “temporary” tools is the technical debt you carry longest.