Weave Code
Migrator Laravel Package
statamic/migrator
Statamic Migrator brings Laravel-style migrations to content, letting you define repeatable migration classes that import and transform external data into Statamic collections and taxonomies, run via Artisan.
Statamic Migrator is a Statamic addon that brings Laravel’s database migrations into the Control Panel. It lets administrators review migration status and run pending migrations without opening a terminal, helping keep content and schema changes in sync.
- Run pending database migrations directly from the Statamic CP
- View applied and pending migration status at a glance
- Use a simple utility screen for safer migration workflows
- Reduce reliance on CLI access during site administration
Frequently asked questions about Migrator
- What does statamic/migrator actually do?
- The package is published by Statamic as an addon that surfaces migration status and pending migration runs inside the Control Panel, and its blurb describes defining repeatable migration classes that import and transform external data into Statamic collections and taxonomies. Those two readings point at materially different products: a Control Panel wrapper around Laravel database migrations versus a one-shot content importer for Statamic v2 to v3. Treat the broader schema-as-code use case as unverified until you read src/ServiceProvider.php and src/Console/ yourself. A half-day spike settles the scope before you build an adoption plan around it.
- How do I install statamic/migrator?
- Install it with Composer as statamic/migrator, but put it in require-dev on a throwaway migration branch rather than in your production dependency set. Because the package operates on flat files and never sits in the request path or owns a database table, it has no runtime footprint and no reason to ship with your application. Pin it to an exact version and plan to remove it after cutover.
- Does Statamic Migrator run Laravel database migrations or import content?
- The overview describes running pending database migrations from the Control Panel and viewing applied versus pending status, while the package blurb describes migration classes that import and transform external data into collections and taxonomies. The documentation ambiguity is itself a risk finding, so verify behavior rather than assume it. The command surface registered in src/Console/ is the fastest way to tell which product you actually have.
- Which Statamic and PHP versions does statamic/migrator support?
- It is built to bridge one specific major-version pair, Statamic v2 to v3, on PHP 7.x-era and Laravel 5.x/6.x-era tooling. Both sides of that matrix are legacy, so if your source site has drifted onto a patched PHP runtime or carries custom addons, the compatibility window closes quickly. Confirm the constraints from composer.json in week one, because this is a hard version gate that no configuration can work around.
- Do I run it with php artisan or php please?
- Whether the commands register under php please or php artisan is the tell for how the addon is wired into Statamic. Read src/ServiceProvider.php first and then src/Console/ to see exactly what is registered and under which namespace. This single detail resolves most of the confusion about what the package is designed to do.
- Can I roll back a migration if the content import goes wrong?
- Do not rely on down() as a true inverse for content writes, because reversing file and entry transformations is not equivalent to reversing a schema change. There is no transactional rollback for migrated data, so a snapshot-based restore of the destination install is the real safety net. Take a full backup immediately before every run, including assets and any addon-owned tables.
- What content does it not migrate, such as globals, navs, forms, or multisite?
- Coverage gaps are the default rather than the exception with importers of this kind. Globals, navs, forms, revisions, drafts, multisite and localization directories, user passwords, asset metadata and focal points, and custom fieldtype reference data are the classic silent-loss surfaces. Absence of errors during a run is not evidence that content arrived, so audit each of these explicitly after migrating.
- Is statamic/migrator safe to use in a production Statamic site?
- Production blast radius is low by construction because the addon has no runtime footprint and never serves requests, but it does write content into a destination install, which is the risk that matters. Run it against staging or a fresh v3 install first, snapshot before each run, and confirm the migration is safely re-runnable as a delta if you need to process a large asset library in batches. Chunking behavior for large libraries is worth verifying in source rather than assuming.
- Is statamic/migrator actively maintained and who supports it?
- First-party Statamic provenance is a genuine maintenance signal, but it is not an SLA and does not guarantee patches for your edge cases. The package has a small community footprint, roughly 43 stars and zero dependents, so there are no blog posts or Stack Overflow answers to fall back on. Escalate issues through any Statamic support agreement you hold, and assume you are the QA for your own migration.
- What are the alternatives to statamic/migrator?
- If you are not on Statamic v2 targeting v3, feasibility is effectively zero and no configuration changes that. The realistic alternatives are a fork of the addon, a bespoke ETL script, or stopping the migration entirely. Budget the counterfactual of roughly two to six engineer-weeks of custom ETL plus QA as your business-case anchor, and remember the tool compresses only the mechanical share of that work, not the judgment calls about what correct output looks like.
Weaver
How can I help you explore Laravel packages today?