Migrator Laravel Package

Product Decisions This Supports

• Upgrade vs. rebuild vs. sunset — the core platform call. The package exists to answer one question cheaply: can we carry existing content forward, or do we fund a rebuild? Its scope — pages, entries, taxonomies, assets, users, site settings — is effectively a written definition of what a lift-and-shift preserves. That converts a vague "we'd basically have to start over" argument into an itemized delta: what comes across, what gets rewritten (templates, custom fieldtypes, addon-owned data, redirects/SEO), and what each of those costs.
• Build vs. buy for migration tooling. The counterfactual is a bespoke ETL script or weeks of copy-paste from the old Control Panel — realistically 2–6 engineer-weeks once QA is counted. A first-party addon with guided Artisan steps turns a bespoke engineering project into a configured, verifiable one. That delta is the number the business case hangs on.
• Roadmap sequencing: bridge, not destination. If you're on an unsupported major, this is a single hop that unlocks supported versions and security patches — not a re-platform. Making the incremental path cheap is itself a roadmap input, because it lets you defer (or avoid) the expensive path.
• Estimation and phasing. "Configurable and repeatable" is the PM-relevant phrase. Repeatable runs mean the plan can be iterative — pilot subset → full run → delta run → cutover — each with a go/no-go gate, instead of one high-variance big-bang weekend. Stakeholders can approve a phased plan with checkpoints; they cannot approve a coin flip.
• Resourcing and skills. Adoption implies someone fluent in Statamic blueprints, fieldsets, the Stache, and Laravel console tooling. This is a staffing decision, not a composer require. Budget an internal fork as a real option: at this size, forking is cheaper than waiting on upstream.
• Cutover risk posture. A repeatable migrator lets you design the release around a short content freeze, a final delta, verification, and a defined rollback checkpoint. Note that rollback for content is snapshot-and-restore, not the tool's down() — that shapes the release plan and the data-snapshot runbook.
• Retiring deprecation and support exposure. Staying on an end-of-life major is a standing security and PHP-compatibility liability. Adopting this is a decision to retire that liability on a schedule you choose rather than one the next PHP release chooses for you.
• Vendor-relationship leverage. First-party tooling is a signal the vendor is investing in off-ramps from old majors — useful when negotiating support terms or when assessing how much to bet on Statamic as a platform.
• Evidence before commitment. A pilot migration of one collection and a sample of entries into a throwaway install is the cheapest possible way to produce a real, defensible estimate for the full upgrade. Fund the pilot as a decision-support exercise, not as the migration.
• Caveat that must be resolved before this anchors anything: the README reads as a one-shot v2→v3 content importer; some surrounding analysis treats it as a general "content-structure-as-code" migrations tool. Those are materially different products with different lifetimes — bridge versus infrastructure. Timebox a half-day spike to confirm the actual command surface (php please list / php artisan list, src/Console/, composer.json). Do not put it on a roadmap slide until that's settled.

When to Consider This Package

Consider it when:

• You are actually on the legacy major it targets (Statamic v2) and your destination is the pair it was built for (v3). Confirm the exact Statamic/Laravel/PHP matrix from composer.json against your toolchain before scoping — a mismatch is a week-one stop, not a cutover-week surprise.
• The migration is content-heavy — many collections, entries, taxonomies, assets and users — where manual re-entry is both the dominant cost and the dominant error source. Volume is what makes a tool cheaper than a script.
• You need evidence before commitment. A pilot subset run into a throwaway install is the cheapest way to convert "we think it's a few weeks" into a number.
• You have in-house Statamic/Laravel competence to read the source, map fields, patch gaps, and own the verification. At 43 stars and near-zero dependents, you are the QA — plan for it.
• You are on a multi-hop ladder (v2 → v3 → current) and want the first hop cheap, reversible, and time-boxed.
• You want a written, defensible inventory of migration risk — the package's supported surface doubles as the checklist of what you must verify by hand (drafts, revisions, localization, multisite, custom fieldtypes).

Look elsewhere when:

• You are not on v2, or your target is a later major. A two-versions-back addon does nothing for a modern upgrade; don't let its existence anchor you to an outdated plan or justify staying put.
• Your site is small and bespoke — under a few dozen entries, a hand migration or a one-off script beats configuring a tool and validating its output. Tooling overhead dominates.
• You need a vendor SLA, guaranteed version support, or a contributor community. First-party provenance is a genuine signal, but it is not an SLA. If you can't absorb an internal fork, that's a stop.
• Your content model is dominated by custom addon data the tool doesn't understand. Mapping becomes the project and the package becomes a rounding error.
• You haven't decided the legacy site is worth migrating at all. Sunsetting or rebuilding may be cheaper — and a migration tool can quietly make the wrong decision feel inevitable because it made it feel cheap.

How to Pitch It (Stakeholders)

To executives: We're running a CMS version that no longer receives security updates — a standing risk we pay for in incident exposure and in engineer time spent on workarounds. This is the vendor's own tool for moving our content, media, and user accounts onto the modern version instead of rebuilding them by hand. The business case is straightforward: it replaces an estimated multi-week custom engineering project with a configured, re-runnable process, and it lets us prove the migration on a copy of the real site before we commit a release window to it. I'm recommending a small, time-boxed pilot — one collection, a sample of entries and assets, run into a throwaway environment — that gives us a real estimate and a go/no-go on the full upgrade. Two things to be clear about: this is a bridge to a supported version, not a re-platform, so templates and custom functionality remain separate work; and because the tool is new and thinly adopted, we should budget for our own engineers to own validation and possibly a maintained fork. I'd rather fund that deliberately than discover it at cutover.

To engineering: Treat this as require-dev on a migration branch, pinned to an exact version — it's a bridge, not infrastructure, unless we explicitly decide otherwise. First task is a half-day spike to settle what the package actually is: check src/Console/, the service provider, and composer.json, and confirm the version matrix against our toolchain before anything else. Assume the shape is pilot → full → delta → cutover, with written go/no-go at each gate. Working rules: one logical change per run, idempotency guards at the top of every step, stache:clear after structural changes before concluding anything, and git diff on content/ and resources/ as the primary verification harness. Snapshot content/, users/, resources/blueprints/, and resources/fieldsets/ before every non-trivial run — content rollback is restore-from-snapshot, not down(). Explicitly verify drafts, revisions, and locale directories survive; absence of errors is not evidence of presence. And we need a written policy on CP-vs-migration source of truth before anyone touches a blueprint in the Control Panel.