Should project config be used during development when migrating from Craft 2?

Question

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,

Answer 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 for large sites where you might be regularly running the migration process during development and testing I would strongly consider ignoring project config for this phase. Since I originally asked the question project config 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 but it still is potentially an headache if for example, you have project config data and decide to do a complete teardown and run all migrations for Craft 2 to 3, you'll potentially get weird errors and issues due to a conflicting database state.

You previously could disable project config in the earlier Craft CMS 3 versions, you actually can't now for the most part given how much it is leveraged in the core Craft classes but you can prevent any YAML files being written out: https://craftcms.com/docs/3.x/project-config.html#manual-yaml-file-generation, so the database remains the only source of truth.

I would recommend 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.

Once live, you'll want to follow the steps here to enable project config across all environment in a consistent state: https://craftcms.com/docs/3.x/project-config.html#environment-setup