🤘 Make migrating from v2 all the moar easier!
📺 See the migrator in action in this screencast.
The site migrator is the recommended way to migrate your site. To get started...
-
Install a fresh instance of Statamic in a new location, and require the migrator:
composer require statamic/migrator --dev --with-all-dependencies -
Clear your new site to ensure all default content is removed prior to migration:
php please site:clear -
Ensure you are running the latest version of Statamic in your v2 project.
-
Copy your v2 project's
sitefolder, as well as any local asset container folders, into the root of your new project.- If you were running above webroot, be sure to copy your
public/themesfolder intosite/themesas well.
- If you were running above webroot, be sure to copy your
-
Commit all your changes up to this point, so that you can view a diff of all the changes performed by the migrator, and easily rollback if necessary.
-
Run the following command to initiate the migration:
php please migrate:siteNote: For transparency, Statamic pings home to record statistics about how many things are migrated. This data is completely anonymous, but you can opt-out by adding
DISABLE_MIGRATOR_STATS=trueto your .env file! -
Address any errors and warnings, and re-run
migrate:siteuntil there are no remaining issues.-
Use the
--forceflag if you would like to overwrite previously migrated files. -
While we hope to automate most of the common tedious stuff for you, anything more custom may need to be manually migrated. Checkout the upgrade guide for more info on breaking changes.
-
-
When you are finished and happy, feel free to delete your
siteand asset container folders from your new project's root, and then run the following commands:composer remove statamic/migrator --dev composer update -
Order pizza! 🍕 🤘 😎
If you require a more granular approach, you may also run the individual migrator commands. Please read using the site migrator before starting, to ensure everything is properly prepared for migration.
In v3+, blueprints are the replacement to fieldsets. It's worth noting that fieldsets technically still exist, although they are a now a smaller, companion feature to blueprints. To migrate a fieldset to a blueprint:
php please migrate:fieldset post
In this example, post is the fieldset handle.
In v3+, collections have a slightly different folder and config structure. To migrate a collection:
php please migrate:collection blog
In this example, blog is the collection handle.
In v3+, pages are now stored as a collection, with a separate structure to manage your page tree hierarchy. To migrate your pages:
php please migrate:pages
In v3+, taxonomies are mostly plug-and-play, apart from a few minor changes to config structure. To migrate a taxonomy:
php please migrate:taxonomy tags
In this example, tags is the taxonomy handle.
In v3+, assets and related meta data are now stored within a Laravel filesystem. To migrate a local asset container, you will need to copy your assets folder into your new project's root, along side your site folder. You can skip this step if migrating an S3 based container. Once ready, run the following command:
php please migrate:asset-container main
In this example, main is the asset-container handle.
In v3+, globals are mostly plug-and-play. To migrate a global set:
php please migrate:global-set global
In this example, global is the global set handle.
In v3+, forms fields are now defined in a blueprint. To migrate a form and it's submissions:
php please migrate:form contact
In this example, contact is the form handle.
In v3+, users are mostly plug-and-play. The most notable change being that email now replaces username as the new file name and handle. To migrate a user:
php please migrate:user hasselhoff
In this example, hasselhoff is the username handle.
In v3+, roles are mostly plug-and-play. The most notable change being that roles are keyed by a slug handle, instead of by uuid. It's worth noting that the user migrator takes care of this relationship on the user end as well. To migrate your user roles:
php please migrate:roles
In v3+, groups are mostly plug-and-play. The most notable change being that groups are keyed by a slug handle, instead of by uuid. Also, we've removed the users array from each group, in favor of storing a groups relationship on the user itself. It's worth noting that the user migrator takes care of this new relationship on the user end. To migrate your user groups:
php please migrate:groups
In v3+, site settings are now stored in a conventional Laravel config directory. To migrate your site settings:
php please migrate:settings
Due to the fact that settings vary between v2 and v3+, we cannot guarantee a complete migration of your settings, but we attempt to update the most obvious stuff for you. Be sure to double check that all of your important settings were migrated as needed!
In v3+, the concept of 'themes' is gone. Your site just has the one, and it's in the resources directory. When running a full site migration, we only attempt the migration of your active theme. However, you can specify any theme handle when running this migrator individually:
php please migrate:theme redwood
In this example, redwood is the handle of a theme located in the site/themes folder.
It's worth noting that antlers templating has undergone a fair number of changes. The most obvious change is that antlers now uses the .antlers.html file extension. You'll also notice changes in the available tags, modifiers, and how variables cascade, etc.
Due to the evolution of antlers templating, we cannot guarantee a complete migration of your theme, but we attempt to update the most obvious stuff for you.
While we hope to automate most of the common tedious stuff for you, anything more custom may need to be manually migrated. For this reason, we recommend getting familiar with the upgrade guide. Though we can't automate everything, hopefully you have found this package useful in your transition to v3+. If you come across a bug or issue that you think needs to be addressed, please open an issue.