Estimate effort to migrate to the new block editor

[bobbingwide]

Migrating existing sites to use the new block editor could be a massive task. Each developer / site owner will need to develop an implementation plan that evaluates the current situation and where they want to be some time in the future. The effort to migrate varies from one site to another.

Requirement

• Develop some effort estimates and tools to help track the migration process.
• Develop routines to estimate the cost of converting plugins - e.g. from shortcodes to blocks
• Develop routines to estimate the effort to evaluate Gutenberg's compatibility with existing site's code and content.
• Develop routines to automate the effort of evaluating compatibility.
• Develop routines to determine the cost of migrating content to the new editor.
• Develop routines to automate the migration of content to the new editor.

Stages

1. Initial evaluation - determine the size of the problem
2. Adjust estimates
3. Prioritise effort
4. Develop a plan
5. Implement plan
6. While not complete
7. Track against the plan
8. If required adjust estimates, re-prioritise and re-plan

1. Initial evaluation

Produce high level estimates of the effort involved

• Evaluate Gutenberg's compatibility with installed sites
• Evaluate Gutenberg's compatibility with own plugins / themes
• Determine Gutenberg's compatibility with 3rd party plugins / themes
• Determine effort to convert shortcodes to blocks

Initially assume the worst and that absolutely everything has to be done to avoid disaster. Use finger in the air effort estimating based on recent experience, known issues and system complexity.

2. Adjust estimates

Drill down into the first sets of results to determine which tasks can be eliminated.

3. Prioritise effort

• Based on risk assessment; likelihood of a problem occurring times instances where this may occur.
• Based on most logical sequence for implementation

[bobbingwide]

To evaluate the existing site content we'll develop a [content] shortcode that will count the number of posts for each registered post_type and determine how many posts there are which are potentially editable using the block editor. The [content] shortcode will produce a detailed report for each post type and a summary report grouping post types and counts.

The totals from each report can be accumulated in a spread sheet to enable analysis of the current state of affairs and the predicted state when post types are enabled for the block editor.

[bobbingwide]

I recently published a blog post entitled Gut feeling - estimating the cost of migrating to Gutenberg.

The high level figures, were

1. Gut feeling - 33% compatible content
2. Development effort - 200 days
3. Peaceful coexistence - 1 - 2 days per site
4. Actual migration - Unknown

The herbmiller.me site has Gutenberg activated, plus the oik-block plugin. The blog post uses the prototype CSV block multiple times. The post was initially written in a local version of the site ( qw/hm ) then the content was cloned using oik-clone. During the cloning process I discovered more areas of incompatibility. And during subsequent edits of the post on the live site, more places where unexpected problems in PHP land lead to very unexpected responses in REACT land.
Each of these problems have been raised as issues or comments on issues.