Email migration to Office 365: Part 3 – Technical Considerations
In the first part of this series we took a look at the reasons to migrate email to Office 365 and how you can make your project a success. We followed this with a discussion on common mistakes made during migration. Next, we’ll be examining some of the technical prerequisites you should be aware of.
Preparing the groundwork
Unless you have simple requirements and a small environment, lifting-and-shifting your email data into Office 365 isn’t going to be a viable option. There’s likely to be a wide range of considerations which need to brought into the process before it can start. Questions about policies, existing technology, migration type, and timelines need to be addressed before your project can commence.
Your overall migration strategy needs to be governed by a comprehensive information management policy. This provides the basis for determining what data must be migrated for legal and regulatory reasons, and what can be disposed of as having no business value. Many organisations decide to attempt a partial migration in the first instance, but once they begin to evaluate the state of their data, they find it necessary to move everything as some files could present risks in their current state.
Throughout the process, it is vital to track any changes, monitor progress, and keep a full audit trail of activity. You can attempt to do this manually, but using reports from live tools is far more reliable from a quality control and resource management perspective. There are plenty of third-party solutions around to help with this, although some are more comprehensive and user-friendly than others.
Certain technical requirements should be considered before you start a migration project. These may include:
- Performance and capacity of servers and networks – Even if your existing infrastructure isn’t bursting at the seams, you won’t want to overburden it and grind systems to a halt. The most important thing is for business to be able to continue as normal while data is collected and migrated.
Your chosen migration solution may involve provisioning dedicated hardware. This can be an opportunity to repurpose old hardware – or to purchase new hardware with the intention of subsequently repurposing it into your production environment.
With some migration solutions, software may run in the cloud and you won’t need any special hardware. However, the reliability of your wide area network (WAN) is even more important, as again you don’t want to choke normal business data traffic.
- Backup windows – Backups are often run outside normal working hours, i.e. at the same time you’ll want to be transferring data during migration. These need to be scheduled so that neither process compromises the performance of the other.
- Permissions to access data – Permissions need to be set on all source systems before data gathering commences. Where local files, such as PSTs, need to be accessed on individual machines it’s important to communicate with staff and explain the reasons for access.
- Security issues – Misconfigured proxies and firewalls can be blockers to migration, as can over-zealous security procedures that mean extensive customisation to the migration tools being used.
- Problems with existing implementation – There may be corruption or stability problems with your current Exchange implementation – maybe it has some peculiar plug-in configuration, or it may have existing business process baked tightly around an old version (e.g. Office 2003) that Office 365 doesn’t readily support. These need to be fixed before your migration project can commence.
- Specialist resources – If some of the necessary skills are available in-house it’s often necessary to employ external consultants to help with project governance (or even to carry out the hands-on work). Appropriate planning and tool selection can often reduce the cost associated with hiring specialists.
Assuming these initial considerations have been addressed, what else do you need to be aware of?
A matter of scale and complexity
Scale and complexity are big factors in delaying or obstructing migration success. Email migrations are far simpler when they take place on a smaller scale, and the migration features available in Office 365 should be able to deliver a smooth and rapid transition for smaller, simpler environments.
But what happens if you have more complex needs?
Many organisations have multiple offices scattered across different locations, and if some, or all, of these sites are running different versions of Exchange (or if they each have their own archiving system) the process can become extremely confusing and very slow. If you have one or more of these kinds of complications, especially when you’re migrating a large environment, it might be time to seek third-party assistance. There are plenty of tools and services available to deliver better management, speed and efficiency when it comes to enterprise-scale migrations, as well as management of your Office 365 environment once you have migrated.
Assuming you have already established the compliance and retention imperatives you need to achieve from your new environment, you face three main questions:
- How do I minimise the data volume I need to transfer?
- How do I ensure that I don’t break the existing logic and interdependencies within my system?
- What do I do with the stuff I no longer need?
In the next blog in this series, we’ll start by looking at data volume issues.