Best practices for migrating theme with block tyes

Developing with Concrete
1

Hello dear Community,

I am seeking advice for the following issue:

I plan to upgrade a website from 8.5.7 to 9.4.7. The current site uses a theme that comes with a few blocktypes which are all prefixed with the theme handle, like “themehandle_blocktypename”.

The Theme does not exist as being “Version 9 ready”, so I want to change to a selfbuilt, bedrock-based theme. I want to build the theme, create all necessary pagetypes and blocktypes, run the update and change to the new theme.

Now - for a smooth transition, of course it would be best if the blocktypes just exist in the new theme, but as the blocktypehandles contain the themehandle, this seems messy, as I would have “btThemehandleBlockhandle” in the database, even if the new theme (which I am building myself) will have another name/handle.

What do you suggest? I see these options:

  1. Rebuild the necessary blocks, keep the old themehandle and accept the mix of handles (looks messy / inconsistent)
  2. Rebuild the necessary blocks, change the block/themehandle in files and database (fiddly work with many possible errors)
  3. Manually change to blocktypes that come with the bedrock/atomik based theme (horrible much manual work)

What do you think?

Thanks for your feedback!

2

(3) Is the cleanest strategy, but as you note can be a lot of work. You could audit the usage of the problem blocks. If a block is only used in global areas or on less than N pages, editing in a v9 block can be lower risk, not disproportionate work, and better for the future.

The big question is “what value is N ?”

My experience of migrating sites is that when comparing manual migration to developing more technical process is that N can be surprisingly large. If there are <100 pages containing the problem blocks, I would definitely go the manual route of editing v9 blocks. Once the number of affected pages gets to 250, that is definitely in the grey area. Once a site is 1000 pages, its definitely worth developing a technical solution.

Also consider, does the site need all current pages? So look at the site analytics and see which pages are actually visited. Look at the business and consider which pages are relevant. For example, does anyone need or read blog posts from 3 years ago? Can you prune pages rather than converting them?

You can also get the customer involved. Perhaps they can do some of the manual editing.

Now for pages/blocks that don’t fit into (3). For (1), its only other developers who will see the inconsistency in table names. Site admins will see the block type name. If that is OK you don’t need to run into the complexity and risk of (2).

As a 4th option, you may be able to export pages as XML, run an edit macro on the XML, then import the edited pages. You can also dump the database SQL, edit that, and re-import.

In practice, your solution will likely be a combination of strategies.

I often find that a major updates start with pruning and cleaning, getting the database to a minimum. Then (4), often with a few iterations, sometimes with (1) or (2) inside or after. Then (3).