Migrating from Business Catalyst

This happens all the time

Proprietary platforms pivot and shutdown all the time. The business changes direction, they discontinue important features or develop myopic outlooks that only serve one small segment of their customer base. This happens all the time and because of that, we have been forced to develop, iterate and test an array of migration services built specifically for the various proprietary platforms that exist.

Since Adobe's announcement in 2018, migrations from Business Catalyst (BC) has long been a specialty of ours. Our process completely streamlines the re-platforming of any BC website which can be further customised and expanded upon for any project-specific functional requirement. In fact, we've managed to cut development costs by as much as 80% when using our framework to deliver projects. For each one of our clients, this ultimately means:

• Less development costs overall,
• Fewer support costs and on-going fees,
• No on-going annual Platform License Fees, and
• No project risk.

Migration plan

Planning is critical to the success of any project and with migrations in particular, there is a real opportunity to rethink and reconsider various aspects of a website that could be improved or even omitted as part of the exercise. Because of this, below we've documented our 8 step migration framework that we hope will help minimise the impact on your business and offer a seamless solution for the migration of your BC website.

It should also be noted that when using our framework to migrate BC websites, it's not uncommon to experience higher search engine rankings and improved website performance.

Step 1, planning.

So, where are you migrating to? This next decision regarding technology is crucial. After all, you don't want to invest in another platform only to have it shutdown once again...

By now, you've probably got a large list of existing functional requirements, and some you'd finally love to implement as part of this migration exercise. Well, what are they? How would you describe each of them? To do that, you need to make a list. Yes, like a straight up normal list on a piece of paper. Write down everything that you can think of and don't worry too much if you forget anything. We'll find it :)

Step 2, technology.

As with any investment in technology, the central theme of this migration should be extensibility. I.e. To provide for change - typically enhancements, while minimising any impact to existing system functions. And why is extensibility important? Because you don't want to invest heavily in technology and then need to start again... As mentioned above, this truly is a great opportunity to rethink and reconsider what functionality is actually required and what could be improved or even omitted as part of the migration exercise.

Blog and News. Forms. CRM and EDM integration. Ecommerce... Working through the list you've made (above), we'll soon start to see patterns and formulate a sharp and deep understanding of how things are connected. We'll map all of this with you and demonstrate technology that will meet and exceed your expectations. This will include a list of relevant and well-supported modules that we'll use to facilitate the majority of your functional requirements, as well as anything custom that you'll need to facilitate any outlying or bespoke features.

Step 3, site files.

In order to migrate away from BC, you'll need to get a copy of the website's files. Unless you already have them, you simply need to request them from your current service provider. Send them an email with the following list and ask for the first item. If they say no (for whatever reason), ask for the second etc.

1. Direct Code Repository access;
2. A copy of the Code Repository;
3. SSH access to live web server;
4. SSH access to another web server that contains as exact copy of the website;
5. A complete copy of the site's codebase (including media directories).

Failing all 5 of these, you will be forced to completely rebuild the frontend of the website as part of the migration - more on this below.

Step 4, design & frontend

The UX and UI of your website is fundamental to its success. And if you've successfully built a BC website, chances are you've spent a lot of time, effort and money on designing it. Therefore, when it comes to migrating a website away from it, there are 3 ways to approach the design and frontend of the project:

1. Re-use the existing website's frontend and current designs;
   To do this you'll need to be successful with your request for site files (above).
2. Re-build the existing website's frontend and current designs;
3. Completely redesign and re-build website frontend from scratch.

There are various pros and cons associated with approach, but ultimately the decision should come down to the project's requirements and objective of the migration. If time is a critical project factor and the existing BC website performs well from a usability standpoint, the 1st option would be ideal. If the website's frontend contains various errors and or you were unable to obtain a copy of the website's files, then option number 2 would be necessary.

If you had the time and the website required various updates and improvements, then option number 3 would be the best direction to take. Please note though, that this option will also increase the budget required for the migration.

Step 5, development & testing.

It's here that you'll actually start to see the process of "migrating" your BC website, and what comes next will be an extremely exciting and efficient process.

Working with the website's existing frontend (which you've obtained in the previous step), we'll run a series of automated and purpose-built tools to orchestrate and integrate a model of framework and CMS requirements which we'll deploy (almost immediately) to a dedicated staging environment. Testing and content (training and input) as detailed below, comes next.

Working with you every step of the way, we'll ensure that everything we "migrate" is an improvement.

Step 6, content & CMS training.

Content is such an important and yet, often underestimated or undervalued task. To be clear, when I talk about content, I'm talking about what makes up the site itself. Pages, posts, files, images. Basically, all the things people look at when they come to your website and for the most part, there are 3 distinct groups of content.

Static, mostly unchanging content, such as:

• Terms and Conditions;
• Privacy Policy;
• Support Pages;
• Return Policy;
• About page.

Dynamic content, which often changes:

• Blog, News & Events;
• Category pages;
• Product pages;
• Customer/User Info;
• Home page.

And files that you, or your users have uploaded to the site:

• Images;
• Videos;
• Downloadable PDFs;
• Sizing Guides or Instructions.

Now, depending on the size of this "content" task, there's usually some merit in taking time to review the website's content and once again, decide on whether or not to improve or omit various things as part of the migration exercise. But if time is of the essence and your contract with BC is soon expiring, it may be best to first complete the migration and then perform your content review.

Using Google Analytics, you should be able to see what content is actually driving engagement and therefore, you can make decisions on what content to keep and what to remove. By removing content that doesn’t help your website achieve its goals, you'll not only decrease the time and costs associated with the website's migration, but improve its performance once deployed.

Step 7, benchmark performance

It's important that you benchmark the performance of your current website before you move away from BC.

If you have access to Google Analytics, take a snapshot of your website's performance from the last 12 months. This way, you'll be able to measure the success of your BC migration and to quickly identify any traffic gains or losses post deployment.

Step 8, deploy & optimise.

With development and content all but finished, in anticipation of going live, there are several unique and final checks you should perform to ensure a consistent and high level of polish is applied to the BC migration. These checks often relate heavily to your SEO performance and how well we've migrated your content.

Stepping through these checks, identify any URLs that have changed during the migration process (for better or worse) and rectify them accordingly by configuring a specific 301 redirect which maps the old URL to the new and improved one. For example:

• Old URL: www.yoursite.com.au/blog/blog-category/name-of-article
• New URL: www.yoursite.com.au/blog/name-of-article

Page structure and SEO-friendly URLs are crucial for SEO performance and whilst migrations have been known to hurt SEO performance in the past, if implemented correctly, it should actually boost search engine rankings and improve the website's usability overall.

Conclusion

Ok, so hopefully this helps you minimise the impact on your business by assisting with your Business Catalyst migration.

If you've already begun the discussion or planning of a Business Catalyst migration, then I'd like to wish you all the very best with the project.

And of course, if you need any assistance...just let us know.