Web Migration: Common Overlooked Aspects

When it’s time for a new site, the word “migration” is often dropped in conversations. Every organization looking at a migration in the future will have their own reasons for doing so, their own history, their own future goals.

In this article, we will present the following topics as a means to empower you to recognize aspects of website migration you might otherwise overlook.

• What can a new site look like after a migration?
• Triggers for a migration project
• Paths that might be taken
• Creating the right team

The first two topics are going to feel like the chicken and the egg. Which one comes first? Given the linear nature of articles, they will be presented in said order, but that does not mean the order will match the scenario faced by many.

Read: How to Prepare Your TEAM for a Drupal Migration

What can a new site look like after a migration?

Amazingly, not everyone has the same vision of what a new site might mean. Managing expectations from the start is critical to a successful migration project. Below are some common scenarios that can constitute a “new site” and/or “migration” that you might face in your project.

You will find that the following three categories can account for most changes.

• Server environment change
• Web platform change
• Design and/or functionality change

After this, the triggers that might cause one or more of these changes is presented.

Server environment change

The process of taking an existing site and moving it from one web server to another would be considered a server environment change. It could entail moving your site from your own web servers to an external vendor.

From a new site perspective, this scenario doesn’t seem to fit. Technically, it doesn’t. Same code, same site. However, to your users, it might feel new if the site’s performance has improved. Your site could actually look different, assuming pages weren’t loading fully due to slow performance.

From a migration perspective, this is textbook. You physically move—migrate—to a new server. In the process, you will receive upgraded or new web server features that will need to be configured to work with your site. A few examples include:

• Caching services
• Security configurations
• Development, testing, and production processes.

Your website’s code might be the same, but the environment in which it lives has changed and therefore it cannot be assumed that there won’t be some work to make everything fit and function as required.

Web platform change

First, let’s assume that web platform refers to some type of content management system (CMS). The process of migrating from one CMS to another can yield a site that looks the same, but is it?

From the new site perspective, at a minimum, the code-base is different. The configuration strategy is different. The opportunities to improve or enhance your current circumstances can be different. Given the expense, your new system should be ready to allow for your growth in order to justify the expense.

From a migration perspective, to move your site structure, content, interactions, etc. from one CMS to another is a migration, by definition. Depending how similar the systems and how complicated the existing website, the effort to make the move can be extensive.

Example migration and level of effort scenarios might include:

• Blog: Migrating a blog site from one CMS to another is likely the least complex scenario. Most CMSs are designed around enabling users to post their stories, articles, and blogs with ease so the leap should not be overwhelming.
• e-Commerce/Product site: The level of effort for this type of move will likely be more labor intensive than a blog site. You might be thinking, "A product is a product," but the way the sale is managed can vary from system to system. Check out processes may differ. The way the product is loaded into the system may be simple in one, but the other CMS might offer more sales options that you need to consider.
• Multi-function site: Sites that provide some combination of blogs, products, events, community, manuals, custom integrations, and more will present even more challenges when moving from one system to another.

The pattern should be clear. The more complex the site that is being migrated, the greater the level of effort. This can include new planning effort, where you dig into the metadata level of content and features.

Some CMSs are designed for data micromanagement, and you will want to take advantage of the data reuse functionality such a system provides.

Read: Next Level Tools that Fast Track Drupal Migrations

Design and/or function change

This is one place you will want to manage expectations up front. The scope of work implied by the word "design" can send your migration project into overruns very quickly. And, the idea of functionality (from a site visitor perspective or a content author’s perspective), can be interpreted many ways.

So, from a new site perspective, design and function will create the most obvious new-site feel. Whether it’s the layout of your pages, your branding, the way your information is organized and accessed, or the new online tools you add, a significant change will occur.

From a migration perspective, the move is to go from one site to another. This scenario is often combined with the first two: server change and platform change.

Even if it is not, the effort for such a move is not unlike the process of planning, designing, and building a site from scratch. Even if ideas and content and branding are transferred unchanged, a version of the original website’s implementation process will need to be executed.

Triggers for a migration project

Based on the discussion above, it might seem obvious what the triggers for change might be. That is true, to some extent. However, there are triggers that can cause a server change while others can cause a system change. Or both.

Performing a trigger review is a good way to explore the potential, "What about …," comments that can bubble up during development and trigger yet more change and scope creep. In this section, five triggers for change are presented, along with the type of migration that might be required:

• Analytics
• Search engine optimization
• Technology
• Mobile first
• Organizational goals

Analytics triggers

Web analytics are the statistical data collected about website usage. If the site is not being used, can an organization justify the expense of maintaining said site? Not likely, unless the implied triggers for change from said analytics are implemented.

Triggers of this nature can include:

• Bounce rate: Site visitors are not spending enough time on site pages. They aren’t reading or watching or interacting as desired.
• Low or no visits: Pages on the site are not being visited at an acceptable rate. They are either not being found, or their topics don’t meet the visitor’s needs.
• Low or no mobile device visits: Of the visits, users are arriving on the site via a laptop or desktop. This could be justified given the site purpose, or it could be connected to the bounce rate concern, where people leave the page because it is not easily visible in a mobile device.

To remedy these situations, an analysis needs to be completed. Depending on the findings, the following migrations might apply.

• Server change: If statistics are off due to poor performance - pages not loading in a timely manner, for example - a new server environment might do the trick. Cached pages are easier and faster to send.
• Platform change: If statistics are off due to inaccessible pages, pages read by accessibility technology, new code is likely needed. Be it the code for the page structure or the code used to present the content, non-accessible pages can be costly in the long run due to lawsuits, for example.
• Design and/or function change: If statistics are off due to an unfriendly Information Architecture that make site navigation cumbersome, or due to page layouts that don’t fit in the small screens of today’s mobile devices, a new design will be on your list of changes.

Search engine optimization triggers

When a website lands on the first page of Google’s search results, you can claim success. You have made it. Your site will have visitors. Your product will sell. You can now lean back and relax.

Not really. Vigilant monitoring is needed as search algorithms are constantly changing.

What happens if when you aren’t on the first page or if you slip from your pedestal? Something will need to change. What kind of changes? If only there was an easy answer to this question, you would be rich.

There are some efforts you might need to undertake, however. For example:

• Platform change: Using a system that can deliver a semantic web solution is one step towards making a website more understandable. If a search engine can interpret the content of the website (e.g, "price" actually means product price), it’s more likely to index the content of its pages such that they can be delivered to users in search results. How do you think Google creates the images display or the shopping display? With page content it can understand.
• Design and/or function change: In a 2018 blog post, Google stated, "Our advice for publishers continues to be to focus on delivering the best possible user experience on your websites and not to focus too much on what they think are Google’s current ranking algorithms or signals."

The changes you need to make will come from an analysis which will include analytics and possibly user feedback. At the end, you should know what is wrong with your current site and how you might make it better.

Technology triggers

Technology issues can trigger a website migration. With the current rate of change in web-related technology, an older website might already be facing issues that are triggering questions like, "Will our site crash in the near future and leave our customers hanging?"

There are several technology triggers that might send you into migration mode. Here are three examples:

• Non-secure code: Hackers are always looking to see if they can break into your site. Be it a server hack or a site hack, it can happen. And, if you think only open source products are vulnerable, think about the number of security updates you accept from Microsoft on a regular basis.
• Scalability issues: Your CMS was meant for blog posts, not community forums or product sales. You are growing. Your system needs to grow with you.
• Accessibility problems: Yes. This has been mentioned before but given the increased number of accessibility related lawsuits against website owners, it’s worth repeating. Accessibility is just about page hits, it’s the law.
• Lack of mobility: "Mobile-first" is the phrase of the day and rightly so. Most web users today are using mobile devices to surf the net. Are they surfing you?

The type of changes that might be triggered from the list above can span all three: server change, platform change, and/or design and functionality change.

Mobile-first

This drum has already been thumped, but it’s worth mentioning again. We have seen it. "Hey, I was on my phone the other day and saw this cool site. It fit great on my little screen. Can we do that for our site?"

The answer is yes. Given the trend for users to use a mobile device before they reach for their desktop computer, you need join the party. Several technology changes will need to be made to your site.

• Layout plans: Where do the sidebars go when the page is in a narrow display?
• Responsive breakpoints: When does the layout of your page change?
• Menus: That horizontal menu bar will need to change shape in order to be viewable.
• Media adjustments: Are you still offering up media that doesn’t run on a mobile device? Videos, Flash animations, not all formats work. And, don’t forget images. Those 4MG images aren’t going to fly to a mobile device with ease.

What does this mean for migration? Assuming you have the server environment that can manage the increase in your page hits from going mobile, you might need the following:

• Platform change: If you aren’t working in a CMS that allows for mobile first design, you will need to change your CMS.
• Design and/or functionality: As hinted above, page layouts, menus, media will need to be redesigned to accommodate the smaller environments.

Organizational goals triggers

The last trigger worth mentioning is the need to meet organizational goals. There is some overlap here with goals pertaining to analytics and SEO. Other goals might include:

• Additional services: An organization that talks about books might want to add the option to purchase said books versus providing links to external e-commerce service.
• Additional resources: Instead of just selling products, the organization wants to provide an education focused community and tutorials.
• Membership services: Some content might be worth selling right from the browser. The addition of a membership to the website and its valued resources might be the next step to reaching organizational goals.

In each of the examples above, all three types of changes might be required. A new system to provide the new functionality hosted on a server environment that can better handle said changes.

Plus, when such changes are required, it’s likely that other design aspects will need to change, hitting all three types of migration.

Paths that might be taken

Once the migration requirement is identified, there are basically two paths to be taken:

• Do it all now
• Do it in phases

Do it all now

There are two scenarios that easily lend themselves to this approach.

• Migration projects such as server changes are at the top of this list. Copy the site to the new environment, test it, fix it if necessary, and go live.
• If the site will undergo minimal changes, getting it all done now is the likely path.

Of course, any scenario discussed above can follow this path to completion. With the right plans, anything is possible.

Do it in phases

There are several scenarios where this approach might be the best approach. Here are three examples.

• Technology threats: The current site has been hacked and off line. Instead of spending time trying to fix a potentially outdated website, select the most important features of the site and spin up a new site as quickly as possible. Then, bring the remainder of the features online as they are completed.
• Legal issues: Lawsuits against non-accessible websites can encourage the need to move quickly. While a new site is being created on a platform that supports accessible websites, two things can occur:
  • Follow the "Technology threat" strategy mentioned above.
  • Take the non-compliant pages offline and bring them back once they have been fixed.
• Budget: The business is growing, but the budget is still tight. Start with the new look and feel on the new platform and server. Get the basics up and running. Then, bring the new features online as resources permit. Two goals to meet in this scenario:
  • Create the design for the full site so that you know it will accommodate your growth.
  • Choose a platform that will allow you to add your new features over time.

Creating the right team

Last, but certainly not least, is the team of managers, user experience experts, designers, developers, and possibly trainers. Who will you need? Without a plan, without an exercise of "What about …?" and "What if …?" scenarios, you aren’t going to know who you will need.

Architecture workshops

From Stakeholder Mapping to the Delivery of Field-Level Blueprints the Architecture Workshop is designed to take your goals and objectives for your website and provide you solid plan.

Whether you develop your website in-house or use an outside firm, this workshop will help you get your stakeholders on the same page and give your website/project manager a blueprint to ensure you get the most out of your developers.

Drupal Developer Immersion Training for your team

Sometimes what you need is a Drupal deep dive for your team. Here is what you'll get from the program:

• Get your developers trained on the latest technology by the best Drupal trainers.
• Learn what new innovations you can implement with the latest Drupal version.

Conclusion

There are plenty of things to take into consideration when talking about a website migration. It's important that you are prepared and that the agency you partner with explains to you fully what would happen to set expectations.

Promet Source has performed numerous successful Drupal migrations. Here are some case studies you can check out:

• Southern Illinois University School of Medicine Drupal 7 to 9 migration
• British Columbia's Knowledge Network Drupal 7 to 9 migration

Want to discuss your own website migration project? Contact us today.