If any of your blocks ship an inner block template, you have a migration waiting with a deadline on it. The template and templateInsertUpdatesSelection properties are moving off the InnerBlocks component and into block type registration. The old props still work. They are deprecated, and the version to have finished by is 7.2.
Mechanically this is dull: the template definition moves out of the JSX where you render InnerBlocks and into the object you hand registerBlockType. The shape of the template does not change. It is largely a cut and paste with a change of address.
The reasoning is the part worth reading, because it tells you which way the editor is going.
A prop is a fact only the renderer knows
A template passed as a prop is known to one component, at the moment it renders, in one browser session. That is perfectly adequate when one person edits one post.
It falls apart the moment two people edit the same post simultaneously. The editor then needs to know what a block's inner structure ought to be without having rendered it in your session at all. That forces the information to be a property of the block type, declared up front, readable by anything that needs it. Real-time collaboration is the feature driving this, and once you see that, the change stops looking arbitrary.
Around twenty core blocks have already been migrated, which is about as clear a statement of intent as the project makes.
The two cases that are not a cut and paste
A template computed at render time from props or state cannot simply move addresses. You have to decide what the block type's declared template is, then handle the variation some other way. And if you were relying on the template changing after insertion, that behaviour was always fragile and is now plainly outside what the API supports.
Grep for InnerBlocks and read every hit. In a plugin of any age you will find blocks you had forgotten shipped a template at all, usually the ones written first. Check bundled third-party block libraries too, because a dependency that has not migrated produces deprecation warnings in your users' consoles with your plugin's name on them.
If you skip it
Nothing breaks immediately. Deprecated is not removed, and the props will keep working for at least a release. What you get is console warnings on every site running your plugin, a slow tax on your support inbox, and the migration still waiting for you.
The version where the props actually stop working is the worst possible moment to find out which of your blocks were affected. Do it while it is a chore.
