Thursday, 8 September 2016

Migrate to G Suite (Google Apps for Work)

Migrating to a different Enterprise Content Management (ECM) system can be a daunting task. After all, these systems (by definition) are meant to be integral to your employee's work. With this in mind, it may seem like a safe choice to put up with your current outdated systems and avoid any migration projects. However, like an ostrich burying its head in the sand, that strategy will only work for a short time. Eventually, the cost savings and added benefits of a modern ECM will be too strong a pull, and--to stay with the bird analogies--the old ECM systems will go the way of the dodo.

When contemplating a migration, you clearly need to consider the opportunity cost you're paying by not switching to a system that better suits your employees and how they want to work. Today, Google Apps for Work (which has been renamed to G Suite) is used by more than 5 million organizations around the world (including 60% of Fortune 500 companies), precisely because it better fits with the modern workforce.

Migrate to Google Apps for Work

Google Apps is a relatively new offering in the ECM space and 'new' in this case represents a more modern alternative to the ECM systems of the past. Unlike most of the other big players, Apps didn't start it's life as an on-premises application that was later shoe-horned into a cloud service. From the first day, Apps has been in the cloud and worked on modern mobile devices.

The upside of migration is a tremendous opportunity to improve the end-user's everyday work experience and significantly improve the organization's data organization and employee collaboration. In this post, I'll introduce the primary questions anyone thinking of migrating to Google Apps for Work (and/or Google Drive) should explore before the migration project begins.

1. What data do we have today?

At face value, this may seem obvious, but the question is far more in-depth than, "What are your Source Systems?" Most IT departments--and we're basing this on years of experience--only need to migrate a portion of their data to a new content management system. In the case of Web Content Management, they might know how many pages they have. For file storage, they should know the total volume of data they're storing, but that information is only part of the picture.

To plan a successful ECM migration, you need to know a lot more about your systems and data. For example, you must understand the source and target permission systems and then find out how you're using your source systems. Depending on the type of data you're migrating, the same can be said for users, roles, files, folders, metadata, email, etc. Discovering what you have today is a vital step in planning for a data migration, so use a tool such as AppBridge Surveyor to generate reports and figure it out. Once you have the data, you can make informed decisions.

2. Which data do we want to migrate?

The basis of this question is the simple fact that it's highly unlikely all of the data you have in your current source systems needs to be migrated to your new ECM platform. Yes, there are exceptions such as legal hold or regulatory compliance, but even then, it's unlikely to apply to all your data. If your organization is like the vast majority, you have a lot of data kicking around that you don't need.

Many projects produce a great deal of files, but once the project is complete, those files are rarely ever needed. Even if you decide that you want to keep every byte of data you have today, that still doesn't mean you have to move it all into the new system. You most likely can archive it somewhere.

Old data is problematic for a few reasons:

A. It makes searching more difficult. I'm sure we can all remember a time we went to a search and the results returned a flood of old data. If you keep everything, it's just a matter of time before it affects your search efficacy.

B. It takes up space. Space usually comes with a price, so keeping unnecessary data is not just a hassle; it might actually be costing you money.

C. If you keep them around, people will accidentally use the old versions of files. This happens all the time because search generally doesn't help a user figure out which file is the most recent. Let's say--just like AppBridge--you've recently upgraded your company logo. If someone is looking for the logo and they search, will the results only show your new logo?

So ask yourself (and your team), what data do you really need?

3. How can we improve the organization of our data?

The fancy term for the organization of your data is "information architecture." If you're not a fan of buzzwords, you wouldn't like this one; it's used heavily in the ECM domain. You can't go to a trade show without hearing an information architecture discussion. But that's not to say this conversation doesn't have value. In the context of a data migration, you are presented with a (possibly unique) opportunity to not just move your data to a new system, but actually make it better.

As already mentioned, simply reducing the outdated data you have in your content management system is one way to improve the situation. But starting with this simple question is also valuable, "Does the organization or your data match your organization and its workflow?"

I don't think I've worked for a company that didn't go through some sort of restructuring, reorganization, or tinkering. Teams are renamed, offices are added, closed, or merged. In short, lots of change. Generally, the organization of data does not keep pace with the reality of how people are working. So forget about what you have today and imagine what would work best for your current reality.

4. What will our new workflow look like?

When you move from one ECM solution to another, there invariably will be some changes. Some of the change might come from a conscious decision to do things differently (read: better), but a lot of the differences will be a result of the way the new system works. Even moving from one version of an ECM system to another could involve changing some aspects of users' workflow--hopefully, for the better. That's not as common these days as Agile software development has led to more frequent and less disruptive releases for many ECM offerings--especially those in the cloud.

Rather than assuming that employees will follow the same workflow, a proper investigation is required on the target system. This is where a small pilot group is invaluable. After an initial review and recommendations for workflow changes, move over a small portion of your user base and have them work out the kinks in the new system before you do the full migration for the entire organization.

5. How will we prevent interruptions for our users?

When discussing migration projects with people, many cite the disruption to their users as the main obstacle. It really doesn't have to be that way. I'm going to try and avoid turning this post into an ad, but if you investigate migration software, you'll find that solutions such as our own AppBridge Transformation Suite for Google Apps and Google Drive can provide zero-downtime migrations to Google Apps.

Most likely, you'll want to migrate the bulk of your users during non-working hours. If you have a small enough user base and a small enough volume of data, you might be able to migrate over a weekend. However, for larger organizations, or larger data stores, that's simply not possible. Even when dealing with 'fast' networks and modern systems, there are still limitations. But none of these issues are necessarily a deal-breaker. If you're using a sophisticated migration solution, you will be able to migrate over the bulk of your data, and then migrate over anything that has changed since you began the migration (the "deltas"). This functionality allows for minimum interruption and zero downtime for users.

6. How will we sufficiently test our migration?

The story goes that the original HealthCare.org project team reduced their testing period from months to weeks, and they ran their performance stress tests the day before the launch. It was the most highly publicized failed project of the century (so far), and any project manager worth their salt could have looked at the schedule and seen red flags. Testing isn't optional--it's not an add-on to the project. This is just as true for data migration projects. Remember the mantra: Test early and test often.


7. How will we run our user training?

I assume many people would guess that the data copying phase of a migration is the most challenging. That's not necessarily true. Without proper end-user preparation and training, user adoption issues can sink an otherwise successful data migration project.

Before you begin your migration--and before you begin your pilot--you should take the lessons you learned in the workflow evaluation stage and combine that with proper training on the new system. Leaving employees to their own devices can literally scare people, and that's not the start you want to your new system. Even if it's not a lot of time, give people the opportunity to try the new system with sample data (so they can do no wrong) and also the opportunity to ask questions. In large organizations, this can involve nominating people to be the 'expert' for their small team. If you have the budget, this job could be handled by professional trainers. Whichever option you choose, please don't skip end-user training.

8. What will it cost us?

It's obviously impossible to give a range for migration projects; there are far too many variables. Some companies will engage outside consultants to handle the projects, others will use their internal teams. Also, there are different pricing models for migration software. Some solutions are priced by the number of users and others are priced by the volume of data migrated. The only way to figure out your cost will be to get some quotes for the services and software.

One point I would like to make is that the return on investment for migration software is clear. I wrote a blog post on Why Data Migration is Challenging because there are still the occasional detractors who believe they'd be able to custom code their own solution and end up with better results. That road has been tried and over the years, we've seen many of these projects fail and ultimately result in a second project using off the shelf software.

migrate to Google Apps and Google Drive

I hope you found this post helpful. If you have any questions, please feel free to post them in the comments.

BTW -- I'm aware that Ostriches don't actually bury their heads in the sand; that's a myth. What they're actually doing is digging holes for their nests.

No comments:

Post a Comment