1

I'm looking for general advice on the best approach to handle a reasonable sized Craft 2 site to Craft 3.1, related to DB changes.

Because the Craft 2 project is live and constantly changing, I regularly refresh my development environment with a snapshot of the Craft 2 database to test the migration process and to work with the latest data from the live project on my development environment.

One of the first problems I encountered was needing to make development changes to the Craft 3 database. These changes could include, adding new fields, updating entry types etc (that is specific to Craft 3), but obviously wiping the dev DB each time would kill these changes. I'm aware project config can store a lot of the changes I'm making, but the issue I found early on was things would get "reset" from each new migration and generate new UID values for certain fields etc. So if I was to replace my project.yaml file to the version that is committed to source, it would usually end with pain and MySQL failures. This made me think that project config isn't necessarily suitable for this specific development workflow.

My next approach was content migrations. This provides a way to write any changes as a migration which would get applied each time the DB was refreshed, this solves the problem of losing changes, as the migration would run as part of ./craft migrate/all and apply them again. As content migrations have full access to pretty much all things Craft, content migrations themselves are quite powerful, so seem like an option.

From a Craft 2 to 3 migration point of view, would it be best to not use project config during development and only enable project config once the Craft 3 migration is complete? It looks like the general advice is to enable project config, copy the project.yaml from the production site and a copy of the DB and apply this to any dev/staging environment to synchronise all environments and then proceed with a more linear workflow going forward.

Any thoughts or opinions on this would be appreciated!

Thanks,

1

I'll answer this for the benefit of anyone else attempting the same thing i.e. sizeable Craft 2 to 3 migration, while you still have the Craft 2 site live.

Ultimately, I chose content migrations and chose to basically ignore the projectConfig functionality for the most part during development. Since I originally asked the question projectConfig changed a bit and got better, rather than it being one big file it is now abstracted out, so it's easier to manage and conflicts are resolved a lot easier now. You previously could disable projectConfig, you actually can't now for the most part, but you can ignore the config/project path at least during development and not check in these files into your source tree, then enable it when you go live and sync the projectConfig files down from production to all environments to then use it going forward.

I chose content migrations because they are repeatable and will continuously test the same logic on any migration run, this verifies for the most part the integrity and conditions that the migration has on each DB migration test and if it fails, it means integrity has failed and it needs to be reviewed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.