You've assembled your content team, determined what content is needed, production is well underway and your workflow is established. There is still plenty to do before you reach the stage of your website project where you have to get the content from your chosen writing platform into your chosen Content Management System (CMS). But it's never too late to start thinking about the migration of your content. The more you can plan upfront for this crucial phase, the easier it'll be as you near launch day.

Whilst you might be solely responsible for the migration, chances are you will be working with others to make this as smooth a process as possible. Other team members involved in migration can include:

• Content Managers
• Project Manager
• Designers
• Developers
• UX folk
• Clients
• Interns (copy and paste all the things!)

Having conversations together as early as possible into your website projects is a great way to get content migration onto the agenda. A kick-off meeting or discovery phase is an ideal time. The outcomes of any migration discussion may influence the way your content is structured, where your content will be produced and the resource you need to get it into the CMS. Let's look at these, and other key considerations, for content migration on website projects.

1. What CMS will be used?

The sooner you can decide this, the better. There are oodles of CMS' out there and each come with their own features and limitations. If you are able to work with the technical team members early enough to agree on the CMS, then this may influence how you structure your content during the planning and production phases of the project.

You may be able to create content templates so that the content is produced in a way that matches the structure of the CMS. Often content is discussed in terms of being published/live, but the technology in which to get it published can be neglected until much later into a project.

Some platforms also require licences so there are fees attached and if these are unknown until much further down the line, then this can have implications for budgets, at a time when clients and teams have already signed off and it can be tricky for additional funds to be agreed and released. Research into CMS', find out if the one you currently use is still meeting your requirements or if a change is necessary. Considering where content will be going in order to be published will help you create future-friendly content.

‍In GatherContent you can create bespoke Templates and structures for your content so that it is produced in a way that maps nicely to your chosen CMS. No more unruly reams of text which have to be broken up and structured during the migration phase.

2. Where your content will be produced?

You may wonder what this has to do with the migration but wherever your content is produced, that's where it needs to move from, into the CMS. If Word or Google Docs is being used for content production then you may end up with content in all sorts of structures and formats that don't allow you to migrate content easily into the CMS.

It can also result in content being all over the place, lack of clarity on the status of content and what the latest version is.Having one central place for content production can also help with maintenance and governance of content once it has been published. If changes to content are required once live, will they be made wherever you write the content, or directly within the CMS? Putting a new website live is by no means the end of the project.

‍By using GatherContent, all of your content will be in one true source for content. If you define a workflow it will keep content on track and if you create structures and templates you can create content that will map nicely into your chosen CMS.

3. How will you get content into the CMS?

This will depend on where you produce your content. If it is Word or Google Docs then a manual copying and pasting mission awaits. This is a common case for many web teams but it can result in errors, as is a risk with most manual processes.

If your team has the resource and know-how then there may be an automated way of migrating the content such as plugins and using an API. Whatever the process, knowing upfront what that process is going to be will help you plan time and resource for it accordingly.

‍GatherContent integrates with popular CMS' and you can migrate content automatically into a CMS using our integrations and API. This reduces the risk of human error and can save both time and money, and perhaps a few headaches too!

4. Who will be responsible for the migration process?

It might be you, a developer, your client, any number of people. Rather than get bogged down in job titles, the key consideration here is making sure someone is responsible for the migration of content and making that person aware of their role and responsibilities.

If it is a client or someone on an in-house team who isn't involved until the migration phase, then you may have to train them on the CMS. This can require time and budget, which will hopefully have been approved during the proposal, scope and deliverables phase.

The person appointed as the 'migrator' may have no technical experience and may not be familiar with certain terminology so they must be educated and armed with all they need to successfully complete the migration tasks. Don't leave it too late to decide who your migrator will be. If they can be involved in chats as early as deciding on the CMS and the structure of the content, then they will be more confident when it comes to the content migration process. Collaboration is key.

‍In GatherContent you can create and assign a migrator role and also add a step to your workflow for the migration too. This will add clarity to what stage content is at, if there is a bottleneck and also how close the website is to being ready for launch.

‍There are also other considerations when it comes to migrating content, including:

• Content variations (such as personalisation or multi-lingual support)
• SEO and meta data
• URLs and redirects
• Maintenance post-launch

Don't wait until you're on the brink of migration before you try and figure out who's job it is, what technology is needed and how it will actually get done. As a project team, discuss the above key considerations as soon as you can (some of this may need to be decided as early as the scoping and proposal phase) and put a plan in place for this crucial stage of any website project.