July 11, 2019
How To

Website Redesigns and Replatforming: Are you overlooking these 21 website migration tasks in your project plan?


Look deep down in yourself and answer this question: Are you a creative or a technologist?

Sure, to be successful marketers, we must wear both hats. But our natural self skews toward art & copy or bits & bytes, Hemingway or Grace Hopper.

As a creative myself, I’ve had to go the extra mile to overcompensate when leading website redesign projects. To help fellow creatives do that, we bring you today’s MarketingSherpa article.

Read on for an easy explainer of key tech tasks from our senior systems manager Steve Beger. Discuss this list with your dev team during your next website upgrade project.

by Daniel Burstein, Senior Director, Content & Marketing, MarketingSherpa and MECLABS Institute

This article was originally published in the MarketingSherpa email newsletter.

It’s human nature to want to stay in your comfort zone. So if you’re a creative marketer in charge of a redesign, you may overly focus on the creative elements of it when building your project plan — design, copywriting, conversion optimization, etc.

However, key technical tasks are equally important as well.

So I worked with my colleague Steve Beger – senior systems manager at MECLABS Institute (parent research organization of MarketingSherpa) – to put together this list of website migration tasks you may want to consider for your project plan, including which tasks can be most easily outsourced. We’ve focused more on the gorpy technical tasks a creative may overlook and not consider when planning a website redesign, and less on front-end development tasks like making the site responsive and visually appealing (which can also be outsourced).

Each and every one of these tasks probably won’t be necessary for your specific situation. But take a quick look at the list below to make yourself aware of some of the necessary activities, and reach out to your technical leads to probe deeper questions where applicable.

But first, consider …

The Macro View: Business strategy

While the individual tasks will be important, make sure your development and technical teams understand the unifying vision for the project. Why should your company do the project, to begin with?

“Before you do any of this, make sure you understand and clearly communicate your needs. What has to be updated? What can persist? Sometimes planning gets ahead of itself, and you lose focus of the actual goal (and that can create scope creep). If your development team doesn’t clearly understand your business needs, they can’t deliver on them for you,” Beger said.

A benefit of clear communication from the very beginning — you might learn that you don’t need to make as big of a technical change as you thought. The current technology platform powering your website may simply be underutilized.

This clear, early communication can also help ensure you take the long view and that the technological changes fit into an overall strategy in the midterm (realizing any technology will necessitate more changes further down the road).

“Another key consideration is scalability. Building a new website is like living in a new home; you may only live in it for five to 10 years. So it’s important to determine your growth path and business needs, building the website to meet them in the near term, and then keeping in mind the need to constantly re-evaluate and see if the future website still meets the needs of where the business is at that time,” Beger said.

The Micro View: Specific technical tasks

Once you’ve communicated the overall strategy, then dive into the weeds of specific technical tasks necessary for a website redesign, replatform and/or migration project. Are you overlooking these tasks?

  • ​​​Research how others have performed a conversion from your current content management platform/system (CMS) to your new CMS — No matter what you’re migrating from and to, someone has likely done it before. The better you get an understanding of what’s involved, the more accurate your project plan will be.
  • Determine how the data is mapped — From content like blog posts and videos to static pages like home and about pages, all the content likely lives in a database. Your website assets (such as images, stylesheets, scripts, PDFs and other downloadable content), may reside within the same location as your website, or even on a CDN (content delivery network like Amazon Web Services or Cloudflare) in some cases. Most often, the database has knowledge of where these website assets may be located. The better your team understands how it is organized, the better you can plan your project.
  • Build a data extractor routine — Pull the data into a universal format for importing into the new CMS (like Wordpress or ExpressionEngine). If the current database storage is built differently than the new content management system’s database format, it may be necessary to export the data, build a data loader routine to create that universal format and then import it into the new CMS.
  • Set up SSL (Secure Sockets Layer) certificate — A secure site is a must these days. It will establish a secure connection between your website host and the customers, help SEO and avoid them being warned about the security risks involved with visiting your insecure site.
  • Create production environment — This is where you will actually host your website, whether on your own server or in the cloud. Your front-end website developers will need access to it.


cid:image005.jpg@01D52110.4234FD60Contractor opportunity: If you don’t have the resources to set up a production environment, you can get a contractor to set up a VPS (virtual private server), cloud hosting (such as hosted WordPress) or an on-premise solution.


  • Run import routines for dynamic (e.g., blog posts) and static (e.g., about) pages — All of the data work your team has done previously will help with this. Make sure they are importing correctly into the new CMS with correct categories, author, date and content. Some fields may be tricky if they don’t map directly to the new CMS. Pay special attention to comments and metadata fields associated with your entries. Makes sure they have correct authors, author info, content, dates and approval status. You may not be able to rely on an application programming interface (API) alone to attribute the correct values to fields like comment date and author info depending on how different the new CMS is from the old one. Most often, there are plugins available with the CMS of your choice, which may help you bucket this data in an organized fashion.  Also, keep in mind, some platforms use proprietary metadata, which may be unnecessary to include in your new CMS.
  • Configure CMS theme — Depending on your business, you may be able to simply use a generic theme that has been established to work on your CMS. More advanced businesses will likely require some level of customization. Either way, make sure the theme is responsive.


Contractor opportunity: Port existing CMS theme into a new CMS format.


  • Set up custom fields — Again, depending on your business, it may be fine to use the standard fields in your new CMS. However, other businesses may need to customize the fields. This may require extending some of the functionality of your CMS with, for example, an advanced custom fields plugin. Another option is to resort to using type-in values, but that could increase error rates and decrease consistency, especially if multiple admins manage your website. Once you have the additional fields setup, it will need to be fitted into your import routine to attribute the correct metadata to each dynamic page (e.g., blog post).
  • Import images and any other assets — You will need to get the images to your new site in some way, perhaps uploading all previously linked assets to the new site. Assets may also require redirection if you can't utilize current asset URLs.
  • Create featured images — Some CMSes will allow featured images for blog posts and articles. These might show up in a directory page or on social media cards. If some of your older posts do not have any images, you can choose to set a default image for all those posts or leave it blank.
  • Build permanent redirects — Redirects can be necessary when the new CMS has a different link structure than the previous one (for example, because nav or categories change or simply because the new CMS constructs links in a different way). In order to minimize loss of link equity (which could hurt SEO), you can redirect any previous URLs to the new URLs in the new CMS and avoid visitors getting 404 pages when clicking through from search engine results or backlinks from others' public sites. This is also required for attributing the correct metadata to each post.
  • Set up site header navigation — This is a fairly easy step with the majority of the time likely spent on styling it appropriately to match your CMS theme.


Contractor opportunity: Build header navigation into the theme. (This should be responsive and potentially drop into a hamburger style menu on mobile/smaller devices.)


  • Set up footer navigation — This easy step should be designed responsively. You can leverage what the new CMS is able to provide for a footer menu, but tweaks may be required for customizing it to your preferences.


Contractor opportunity: Build footer navigation into the theme. (This should be responsive.)


  • Set up social media feeds in footer or sidebar – Your business may not be active on social media, but if it is, it can help to share, for example, your Twitter feed on your website. There are usually plugins to make this happen but there may be a little bit of complexity trying to style it to your theme.


 Contractor opportunity: Build a responsive social media feed module into footer or sidebar of the theme. 


  • Set up interstitial — If an interstitial page, popup form, modal, overlay screen, or something similar (for example, an interstitial opt-in page)  is important to your website, don’t forget to include that as well. You may be able to reuse what is already in place but don’t want to overlook this step.
  • Content review — You’re getting close now. Content review is best done by marketing and content folks, not the development team, since content and marketing teams tend to have a better grasp of how the site’s content should appear.
  • Content fixes — These are based on findings from the content review. Overlooking this step in your project plan can result in a big miss of your launch timeline. Nothing is perfect in the first round; it takes time to fix it.
  • QA (quality assurance) testing — Make sure everything is working as it should across many different device and browser types. This QA checklist is aimed at mobile A/B testing, but you still might find it helpful for your website redesign.
  • Pre-launch — Get all your technical ducks in a row: Analytics and tracking in place, daily backups configured, site behind Web Application Firewall (WAF), set up monitoring (to know, for example, if your website goes down. The CMS may have enough in place, or you may want to get more robust real-time reporting). Aside from the technical aspects, make sure key constituencies know about the website change beforehand (like customer service).
  • Plan a site launch time – Planning a site “go-live” date is critical to mitigating the impacts of any downtime your website may incur. Choose a time when your website may have its lowest amount of traffic to minimize the exposure of your website not looking its sharpest. You may even consider preparing a maintenance page or broadcasting to your audience that your website will be undergoing improvements during that time (this can also help in the instance where data is updated on your old website but isn’t yet carried over to the new one during lengthier launches). Next, begin building a checklist of tasks for those responsible in performing them. Also, identify the activities which can occur ahead of time (this will help minimize time involved with deploying your new website), then the activities which will occur on launch time, lastly any activities which need to occur post-launch time.
  • Launch — Pop the champagne and show the world your beautiful new website. You’ll want to intensely monitor for any unusual or inconsistent behavior at first to make sure everything is populating correctly across the globe, everything is redirecting correctly, it can handle the traffic load, etc. Then continue closely monitoring for the next few days to ensure there are no adverse impacts observed within your website, analytics and any other connected platforms.

“The site migration is never over. You need to continually update and enhance the site. Like any development project, building an application never ends. There are always bugs, security updates, features and enhancements that are evolving. Don’t just launch and forget. What is your long-term strategy to keep optimizing your website — from SEO strategy and SERP placement to site load time and security,” Beger advised.

Related Resources

MarketingSherpa Podcast #5: Ten things you should think about before you do your next website redesign

Marketing Leadership: Aligning the entire team around the unifying vision is an integral part of project management

Website Development: How a small natural foods CPG company increased revenue 18% with a site redesign

Unifying Global Divisions for a Website Redesign: 6 Tactics to Manage the Process

The End of Web Design: Don’t design for the web, design for the min

Improve Your Marketing

Join our thousands of weekly case study readers.

Enter your email below to receive MarketingSherpa news, updates, and promotions:

Note: Already a subscriber? Want to add a subscription?
Click Here to Manage Subscriptions