There are so many great reasons to move your government website from a dated or restricted proprietary CMS to the open-source power of Drupal.
Perhaps you are trying to get away from annual licensing fees. Maybe you were attracted to Drupal’s flexible architecture, accessibility and security. Or you were simply told from your boss you need to move to Drupal!
Whatever the reason, we think you’ll find the grass is greener on the Drupal side. But before you can start, you need to get all those pages and files out of your current site and into Drupal. In other words, a migration. That’s where we can help.
You may think of migration as purely a technical problem to solve. How do we get all of those images, documents, pages, and site features out of one system and into another?
That is a big part of it. But first, let’s start with some planning and discovery.
Content First
Oftentimes a government agency will have hundreds, if not thousands, of “legacy” files and pages that have built up over the past 5-10+ years. These may still be valuable to your team and your audience. But how do you know?
Chances are, even with the best run site, there is content that’s either not being viewed, no longer relevant, messy or inaccessible, or all of the above. For these reasons, we recommend starting with a content inventory and audit.
Make a big spreadsheet cataloging all of your site content. This is your content inventory. There are robots and services to help get us started by crawling your existing site, and this is a process we can assist with.
Next, let’s compare that list against site analytics. What’s getting the most traffic? What’s getting none? Where do we want people to go? This can be a large-scale effort, depending on the size of your site, but one that will pay off in the long run.
Technically could simply migrate every file from your current system into Drupal. But first ask yourself if that’s a good idea.
There’s a saying we’ve all heard - garbage in, garbage out. Migration is an opportunity to clean out your content closets, and rid yourself of all the clutter. This could mean deleting or unpublishing content, rewriting content to be more effective (shorter or longer), or moving internally-focused content off to an intranet.
Audience and Goals
Let’s not forget who the site is for in the first place – your audience. That may seem like an obvious statement, but it’s very common for government sites to “lose their way” over time, with pressures from other departments, different leadership, new initiatives, and different goals, all leading to a site without a clear message and direction.
Migration is a technical process, but as with content, it’s an opportunity to re-evaluate what it is your site is doing and who it is meant to serve.
If possible, we recommend extending the planning and discovery process to revisit your mission statement, define your primary goals and outcomes, and consider what changes may be necessary. This could mean a revised sitemap and navigation, improved user pathways and journeys, tighter messaging on key landing pages, and a fresh new design.
Simply copying and pasting an entire site from an old system into Drupal is technically possible. But all of the discovery steps listed above (reviewing content, reviewing technical needs, reviewing audience and goals) are recommended building blocks to a successful migration to Drupal.
Technical Discovery and Build Planning
The next step in the process of migration is planning your new site build. Every CMS will include features to manage your content and support content editing. But a good CMS is also about structured data.
Through a technical discovery process, we would evaluate everything your current site does (in terms of features, content types, media, design, workflow, permissions, data integrations, etc.), and plan for its equivalent in Drupal. It’s very common to find ways to condense numerous content types into a smaller number, for example, or reducing the number of fields. These are important steps for the long-term health of your website. The fewer moving parts, the more sustainable the site, and easier it is to maintain and keep bug-free.
We’re certain Drupal can do whatever your last system did, and usually better. But we carefully plan the “how” along with the “why”. Coming out of this process is a documented plan for your new site build, so we can move forward with a clear “blueprint” on how to proceed.
Migration is a good time to re-evaluate everything–content, design and build.
With a clear understanding of what we need to migrate, we can now finally move to scripting the actual migration.
If you have a static-based site (i.e. - plain HTML pages), we can skip this step, as there’s no good way to automate a migration. But assuming you have an existing CMS of some kind, there’s an opportunity to automate some or all of the content migration into Drupal.
At its most basic level, this is a process of mapping one content type to another (e.g - news to news, events to events, PDFs to PDFs). It can become very complex very quickly, however!
We recommend a more modern and structured approach to data, using distinct fields and smaller components that are more easily reused and adapted across all mediums. Some sites have all their page content in one big “blob” in the body field, however, along with styling markup and hard-coded links. In those cases, we need to do some heavy scripting to break the data up as it is migrated to Drupal, strip out the styling (so it can be controlled at the theme level), and rewrite URLs to avoid broken links.
Manual vs Automatic
The more you can script and automate machines to run the migration, the less work for your team. But it’s not always so cut and dry. One of the common sense steps to take during any migration process is to evaluate the level of effort to migrate content automatically (via code) versus a manual migration (aka “cut and paste”).
While cutting and pasting content from your old CMS into Drupal sounds very tedious and time consuming, it’s important to consider your options. Sometimes the amount of time it takes to match up content types, fields, databases and files into code takes longer than manually copying it.
It really depends on the amount of content involved. A few dozen pages may not be worth the effort to script an automatic migration. A few thousand files, however, is definitely a task we’d prefer to leave to the machines!
It’s not uncommon to have a combination of manual and automated migrations, where the most difficult and time-consuming efforts are scripted, and the easier ones are left to your team to complete as time allows. Interns are a great resource for this as well, by the way (if you have them)!
To recap our steps so far, we’ve evaluated your content, your goals, and your technical needs, and have written and tested scripts to automatically migrate as much as possible to your new Drupal site. So what’s left to consider or complete? Quite a bit, actually!
Design
A site does not have to be redesigned to be migrated. We can recreate the look and feel of just about any website in Drupal, no matter what system you came from before.
One of the key questions to ask, however, is if you want to keep things exactly the same. As you evaluated your audience and goals and content during discovery, did you find a compelling case for change? Does your existing design still support your primary mission? Is it responsive and accessible? Does it feel dated or hard to use?
There are many reasons to consider a design refresh as part of the migration process. Perhaps one of the most compelling reasons is a practical one. You’re essentially rebuilding your site on a different platform, with its own templating system and probably a different language as well. So if you’re putting in the hours to recreate the look and feel of the site anyway, why NOT consider it an opportunity to refresh or redesign?
Of course, you may be perfectly happy with the way it is now, and/or lack the additional budget for an extensive redesign. That’s fine too, it’s not a requirement with migration– just another opportunity should time and budget allow. A third option is to migrate a site with the same design, and revisit the visual portion at a later date.
Development and Site Build
Knowing what our design (“theme”) is, and having a clear understanding of the site build, our team of web developers will then move into site configuration.
We’ll need a clean and updated installation of Drupal to begin, along with any of the modules and third-party libraries needed to recreate your site. Working from our build and migration planning, we will have the needed content types, fields and editorial tools installed and configured for your team.
Note: this should be done on a web server with staged environments (dev, test, production), so we can do our work of testing and building alongside the client’s content editors.
We can migrate any number of legacy content management systems into Drupal
Testing Migrations
As we work, our migration team is going to run test migrations across all areas of the site to make sure data is being imported accurately. This is an ongoing process, taking place as the necessary components are installed and configured on the Drupal site. Your old site continues to run as normal during this stage, and should continue to up until the new Drupal site is launched.
As the client, your team will have access to the site-in-progress and begin to see content populate the site as time progresses. This is an opportunity for your team to proof and verify that the right content is being migrated, and in a state that is expected.
Typically, there is also a needed step of manually adjusting or reconstructing certain pages of content as we go. This is because your Drupal installation will have different methods for constructing pages and managing layout. This could be a step our team completes, or with training, something your site editors work through instead.
Final Migrations and Launch
Once all of our migration scripts have been tested and verified, we then wait for our scheduled launch period. This allows us to import the most recent content from your existing site, right up to the week of launch. This minimizes the time needed by your site editors to keep two websites in sync (content-wise), while being fully prepared when it is time to launch.
Migrating from one CMS into another isn’t the easiest process to complete, whether it’s to Drupal or some other CMS. There’s a lot of plan and a lot to test, adjusting and tweaking our approach as we go.
But we do have a proven process for it. We’ve completed migrations from a wide range of systems into Drupal for numerous clients in the past–from local governments to the state level.
Thinking of migrating your government site over to Drupal? Let us know how we can help.
Join the Discussion +