The original content is often fully “frozen” during a migration, otherwise a specific piece can be moved over and marked as “done”, and any chances made to the original will no longer be carried over. Even breaking the migration into units or blocks is problematic. Not only are these often interconnected and cannot fully function correctly by themselves, but it’s also hard to tell where you should look for the content that you want to change - in the origin or the target of the migration.
Of course we haven’t discussed the cost associated with the error-prone detailed labor needed for migration, the training of employees on both system for a long while, and so forth.
Enter Stackbit’s visual editing interface that works with any combination of content sources.
The editing interface enables everyone, and particularly nontechnical folks like marketers, to edit content in its context on the page, without going directly to the place where it’s stored (for example a headless CMS). Since it’s agnostic and supports all content sources, even on the same page, in which database the content resides is not important. Finally, pressing the “publish” button in Stackbit also triggers all the separate publishes in the underlying systems, making sure the content you want to be published is, regardless of the system it resides in.
So what does it mean?
1. You might not even need a migration at all.
When the content store is now separate from its editing interface, it becomes less important to move. Clearly if you’re transitioning away from WordPress to a modern headless CMS, and that headless CMS is also your primary editing interface, you’ll want all your content in one place so you can edit it there. Having your users guess whether this title is stored in the old WordPress or the new headless CMS means uncertainty, logging into two (or more) separate systems, etc.
But if you edit visually in context in a central tool anyway, the older content can still live in WordPress and be accessed through an API, while the new stuff, or anything that benefits from the modern infrastructure can be created in the headless CMS.
2. You can migrate at your own pace, without restricting access to the content
Often you’ll still want to migrate, because the old system is sunsetting, because it’s costly, or slow, or a thousand other legitimate reasons.
To avoid that long migration limbo, you introduce your business and marketing team to only one new editing interface - Stackbit. With a rolling migration, your team still edits the same page title week after week, but after a few weeks then writing the changes back into the CMS, instead of writing into the old system, the code syncs to the new one. The marketer felt absolutely no difference, nor should they have.
If the need to update old content is fairly rare or that system needs to have a new content source module created for it, you could also start introducing elements on existing pages, or creating new pages happen entirely in the new system. Only those new sections could be edited, while the originals are displayed but not editable for the duration of the migration.
Finally, since our editor’s interface knows both how to read and write both content and content models / schemas, we can help you with migrations.
3. Make your setup future proof
We know with certainty that soon after completing one migration, another migration is bound to emerge in the horizon. This is ever-true with technology; content management systems, front end frameworks and other tools keep evolving, as do the needs of your company.
Stackbit’s editor is that never-changing pillar that will connect to any content source and to any front end framework, giving your stakeholders a stable tool to work with in a familiar and easy way.
So if a new generation of headless CMS emerges, or your current vendor has become too expensive, gone out of business and so forth, you can change the underlying data store and still maintain the same editing interface before, throughout and after the migration period.
If you’re a digital leader, CMO or architect and want to learn more, please contact us.
You can also start reading about our content source interface in our technical documentation here and here.
