Back to all articles

Top ten tips for international website rollouts

Jonathan Whiteside
Jonathan Whiteside
Global SVP Technology & Engineering
9 min read
22 July 2013

DEPT® has been involved in several successful global website roll outs using content management systems (CMS) and processes that can deliver hundreds of local market websites over the course of a year. Whilst some roll outs can take a year to complete, in one case, we built and released 60 sites, using 9 languages, in only 90 days. So it can be very straightforward, when you know how!

The main things I have learned during my years delivering international roll out projects (with so many tasks running in parallel across multiple teams and people being involved around the world working in differing time zones and languages) is that organisation and communication are the key to success.

I have learned a lot managing roll out projects myself and will share with you here my top ten tips on planning and managing them. If you are about to embark on your own website roll out, I hope you find them useful!

1.Involve the right people from the start

Agree a central team in your organisation who are responsible for the master site and “webmasters” in each country that will manage their own local version. They will be responsible for managing or completing the content creation, content entry, training, site reviews and of course, providing sign off for go live.

A roll out project can last upwards of a year depending on the complexity and number of countries involved, so will inevitably overlap with stakeholder holidays and other responsibilities they have, which you will need to consider when planning the roll out schedule.

2.Understand your IT processes

Involve IT departments and any 3rd party IT suppliers from the beginning and have a thorough understanding of any change control processes that may need to be used.

Over the course of the project there will be requests to create new DNS entries, acquire new domain names, update webservers, restart servers, create new site folders etc. and it is important to understand who will be responsible for those tasks and what the earliest opportunity to complete them is. If possible, get everyone in a room for a day and flesh all this out at the start! You will be glad you did it 2 months in!

3.Keep track of progress across all sites

The same tasks are going to be required for every site that you release and there will be a lot of things going on at once.

We keep track of the status of all roll out activities in a roll out matrix like this one; This matrix lists all of the sites on the left and all the activities required to set them up and launch them across the top. As each activity is started for a particular site, I colour the cell amber to show it is in progress. Once completed, I colour the cell green. If there is an activity that is blocked from happening or isn’t running to plan, I colour the cell red so it’s clear I need to keep on top of it.

It’s a great way to see at a glance what stage each country website is at and what is left to do. It’s also very satisfying to see the whole matrix turn green!

4.Understand your country site unique features and process

There can often be local market specific functionality and content required on country sites. For example, the ability to purchase online in one country or a section on specific local legislation in another country that may not be built in to the new “master” website as standard.

For this I would recommend a full audit of the existing sites prior to the rollout project to allow local countries to identify any content or functionality that may not be built yet for the new site but that is considered business critical in that market. You can then provision the delivery of localised functionality and additional local content within your roll out plan from the start.

5.Be realistic about bugs and issues

There will be small bugs and issues found with every site roll out. Be it issues with text length not fitting into a certain layouts or a template having unexpected layout issues when content is uploaded. The number of bugs found will definitely decrease the more sites are put live, but it’s worth accommodating for a small amount of time for bug fixes and “tidying up” tasks for every website. That way it’s planned for and everyone is aware that it may happen.

6.Don’t underestimate the time required for localising content

Consider who in the local markets is assigned to the creation, translation and upload of the local country content. Remember that localisation is not just translation. It’s about making the content relevant to the local audience. So leave time for sourcing local specific imagery and other assets.

If you assign these tasks to a local country editor who has other responsibilities, and who is only available for your project half a day a week and has never used the CMS, then they will take longer than someone dedicated to your project 100% and familiar with the tools. Preparing a new website to go live is not a small undertaking for a content editor and should not be underestimated. In my experience, it is usually the time required for completing content activities being underestimated that is the biggest risk to hitting your launch date.

7.Make it clear who is responsible for what using a RACI matrix

Planning the review and sign off periods needs to take into account not only the review and sign off of the final site to go live, but also the review and sign off of the Master content, the local translations and the local specific content. Quite often it is a sales, marketing or legal team that must review content, so it is important to ensure their availability alongside other responsibilities to prevent a bottleneck at the review and sign off step.

A good way to ensure everyone knows who is responsible for which area of content is to use a RACI matrix. List the content areas or pages of the site on the left hand side and people’s names across the top, then indicate whether they are a reviewer, approver, contributor or being shown for information purposes only and go through this with the whole team and get everyone to agree to it at the start of the project. This way, it is really clear what people’s responsibilities are on each of the sites and they know what is expected of them.

8.Consider what URL’s to use and have them ready

Quite often existing country sites are to be replaced by the new sites. In this situation consider the need for and URLs to allow you to continue to update and manage the existing sites whilst reviewing, testing and preparing the new ones.

Also think about mapping old URLs to new ones using 301 redirects to update search engine spiders.

9.Plan for large scale publishing activities

If you are creating your new sites in parallel with maintaining your existing sites, consider the impacts on your existing publishing and deployment processes. Doing large scale publishing/deployments of your new sites at the same time as someone trying to publish an urgent press release on your live site shouldn’t be a problem. CMS systems usually allow you to publish your new sites on a lower priority than BAU (Business As Usual) content changes or you can increase the power of your publishing servers to manage the publishing activities required for a set period of time.

We’ve benefited from being able to manage publishing tasks from both our UK and US offices, allowing us to publish new US sites in the UK, whilst the business users in the US are asleep and vice versa!

10. Don’t forget training & support for editors before go live

Consider what training requirements there are for editors and if adding content manually, schedule their training well in advance of content entry activities and go live. We work closely with our clients to ensure training and support is provided for content editors on the project and usually, they then become trainers for other editors internally once the site is live.

Whilst content entry activities are in progress, there are always questions that people have, it’s a new system after all and it will take a bit of time to become familiar with it. We provide content editor support during our roll out projects, through regular catch up calls and demos, as well as answering ad-hoc questions using our online support desk system, Jira. Also having offices based in both San Francisco and the UK means we are able to answer questions and queries across a much longer working day, so it doesn’t matter where in the world the editor is based, we’re there to support them. This helps to keep the momentum going and gives reassurance to those adding content into the new websites that they are not on their own.

To ensure editors are supported once the roll out is complete, we can also provide an online wiki with content entry instructions that can be integrated closely with the CMS platform. This provides easy access to instructions for content authors who only update content every month or so.

There will be of course other intricacies to consider with an international roll out relevant to your operating processes and governance structures, functionalities and local variances than the ten items listed here, but I hope you find these useful if you are about to embark on roll outs of your own.

More Insights?

View all Insights


Global SVP Technology & Engineering

Jonathan Whiteside