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!