Public-sector Drupal migration
Drupal 7 to Drupal 11 Migration Operator Framework for a Large U.S. City Platform
Built an operator-ready Drupal migration framework for a large U.S. city platform, supporting high-volume content movement, domain-filtered rollout waves, repeatable scripts, and editorial validation reports.
Overview
A large U.S. city platform needed a practical path from a legacy Drupal 7 system into Drupal 11. The migration was not just a data-mapping exercise: the source site used Domain Access, contained a large volume of public-sector content, and needed to move through phased rollout waves instead of one all-at-once migration.
The work had to be repeatable enough for operators, transparent enough for content editors, and structured enough to support months of validation and correction without relying on undocumented tribal knowledge.
The challenge
The legacy source audit showed more than 225,000 content nodes across publications, releases, events, pages, biographies, services, and other public-service content types. It also included hundreds of thousands of file records, URL aliases, and domain-access relationships that affected which content belonged in each migration wave.
Because not every domain and content type moved at the same time, migration operators needed a controlled way to run the same process by domain, rerun it safely, capture results, and provide reports that content editors could use to verify issues.
What I built
I helped build a CLI-first migration operator framework with shared, content, and support phases. The scripts wrapped Drupal Migrate commands so operators could run users, domains, files, attachments, content, redirects, related-content linking, and final support tasks through a repeatable sequence.
The workflow accepted domain-scoped inputs, normalized the active domain filter, and passed that context into custom source and process plugins. That allowed the team to migrate content by domain and content type while preserving rerun controls, update behavior, limits for rehearsals, and debug options.
Reporting and validation
Each run produced timestamped artifacts for the migration operators: command flags, summaries, status output, message exports, error extracts, source-to-destination map samples, and machine-readable run records.
Additional reports supported editor validation and follow-up work, including body link reports, file link reports, attachment inventories, redirect exports, and related-content comparison reports. This made migration issues easier to inspect, assign, correct, and rerun during phased rollout.
Outcome
The migration work became a repeatable operating process instead of a collection of fragile one-off commands. Operators could execute controlled migration waves with consistent arguments and artifacts, while content editors had reporting outputs they could use to review and validate issues.
For a high-volume, multi-domain public-sector platform, that structure reduced operational risk: the team could migrate selectively, verify results, correct problems, and continue the rollout without losing track of what had happened in each run.
Planning a complex Drupal migration?
I help teams turn legacy Drupal migration risk into a repeatable workflow with practical scripts, reports, validation steps, and handoff documentation.