A “lift and shift” project involves moving functionality wholesale from one platform to another. In the context of what we do here at Alley, this tends to mean preserving some or all of the design and user-facing functionality of a content-rich website but rebuilding the content management tools in WordPress and re-implementing the design using WordPress themes or modern JavaScript frameworks. It’s a common request, and it can work well under the right circumstances — but creating conditions for success in pure migration projects requires careful consideration of the tradeoffs and, paradoxically, a clear commitment to design thinking.
Wait, design thinking in a project whose sole purpose is to preserve the look and feel of the current site while moving the content tools and infrastructure to a more modern platform? Absolutely! If we don’t understand the business goals of your platform change, we can’t help you execute properly. The process of design thinking starts with empathy — understanding the problem. Often, this is easy enough; we can look at your CMS, note that its design appears eerily reminiscent of Windows Explorer, and understand how that might not work super well for your producers.
One core challenge of projects that are meant to preserve the user experience while moving CMSes is that it is far too easy to build in the assumptions of the legacy CMS into WordPress. This is especially true if the goal of the project is to preserve the actual HTML and CSS that powers the front end since this would require WordPress to mirror the output of the legacy CMS directly. Decoupled sites, where the front end reads from a CMS via an API, tend to be easier to adapt to WordPress without substantial changes to the front end itself.
Still, the challenge of building legacy CMS assumptions into WordPress persists. Content types and taxonomies drive UX elements like navigation, hierarchy, and site search. Legacy CMSes that represent content as a tree present special risks. The kinds of tools we use to deliver enterprise WordPress sites on WordPress VIP are flexible enough to replicate the functionality of nearly any CMS on the market. But rebuilding a legacy CMS in WordPress often means that you miss out on the powerful simplicity of WordPress itself. We largely throw out the assumptions of the legacy system and invent ways to solve problems that preserve the frontend experience while keeping the WordPress backend as lovable as it is out of the box.
As applied to a pure migration project that preserves the frontend IA and UX but changes the backend CMS, design thinking might look like this:
- Empathize: Understand the users and come to see why the current CMS might not be working for the organization despite the continued viability of the front end of the site, the IA, UX, and designs.
- Define: Catalog the opportunities presented by a new system and the challenges extant in the legacy system. Here we want to pay special attention to areas of the user experience that are constrained by limitations in the back end CMS.
- Ideate: The classic design thinking paradigm calls for blue-sky thinking — really crazy ideas. Here, we question parts of the frontend that are tightly coupled to the legacy CMS, and parts of the back end that could be streamlined. When preserving the front end directly in an enterprise migration, it’s tempting to coax WordPress into behaving more like the legacy CMS.
- Prototype: We quickly build a WordPress experience and manually add some content so that editors can see and feel what it will be like to work in the new system.
- Test: We frequently return to our users for feedback to ensure that our solutions are meeting the needs we isolated in the definition stage.
- Implement: Once we’re satisfied with the direction of the CMS implementation, we finalize the data migration pathway and launch the site.
And if this challenge sounds familiar to you, give us a shout! We’d be happy to help you apply design thinking to your own projects.