June 13, 2017 at 10:45

Operation "Migration": if your mail is somewhere there, but you need to be here


    For the last two years, my department has been closely engaged in projects for migrating corporate mail from foreign services to MS Exchange based on the infrastructure of our data centers. From cloud services such as Office 365, Gmail mainly migrate due to FZ-242, because they want mail to live on Russian infrastructure. This is not the only reason: after migration, some companies completely transfer us the mail system for administration under a rigid SLA, which is not always possible in mass services. Those whose mail used to live on hardware and who want to expand without contacting with the purchase of new equipment also contact us, a modest Russian cloud provider.

    Everything happened on 27 migration projects and 50 thousand transferred boxes. Today I want to tell you what you need to consider and think through if you are going to move.

    What do you want to get at the exit


    Before starting the project, we coordinate with the provider the following points:

    • functionality that you expect to receive from the new mail system: traffic volume, calendars, UM, shared folders, etc.
    • Availability at the migration stage and after. Are you ready for downtime? If so, to what extent and when? What accessibility do you expect after migration when your users will work with the new system?
    • what business processes are tied to the postal organization : support services, marketing campaigns, etc.
    • with which solutions you need to integrate (1C, Sharepoint, Skype, etc.). There was a case when an IT manager started migrating mail from Lotus to Exchange, and halfway it turned out that they also had a corporate portal tied to Lotus. They did not plan to move to the new portal, so they turned off migration, and the hospitable manager was fired.
    • approximate dates of migration . Even if everything is correctly calculated taking into account the amount of data that needs to be transferred to a new site, unforeseen technical limitations will certainly come up: the communication channel will be slower than expected, or limits will be found for exporting data from the original mail system.

    We encountered the latter when transporting a client from Gmail. In the process, it turned out that no more than 1.5 GB of data can be exported per day. Even if the box was only 2 GB in size, it had to be exported for two days - 1.5 GB, then we wait a day and load the remaining 500 MB. Moving 20 GB boxes took almost two weeks.

    While everything was exported in small portions, life in the company did not stop and new mail arrived, which also needed to be synchronized with the new site. The problem was solved using the utility Cloudiway: she pulled out the entire contents of the boxes taking into account the daily limit, i.e. we did not have to manually pump out the allowed 1.5 GB once a day. Then she pulled out a delta of letters that fell over while she was pulling the bulk. Over time, the delta decreased and decreased, and after all the data from the source mailbox was transferred, we switched the user to work with the target mail system.

    Another “black hole” where a lot of project time goes is interaction between the project participants. Especially if there are more than two.

    The client migrated from a foreign hosting, and the interaction chain was as follows: we talked with the project manager of the customer, he transmitted our messages to the IT department, which interacted with the foreign hosting provider Exchange. Somehow, we needed to enable MPC-proxy (a service that provides the movement of mailboxes during migration) at a foreign site, and this took two weeks.

    At the start, very optimistic terms are always voiced. Be realistic and feel free to multiply your initial grade by two.

    Audit of existing infrastructure


    Everything is simple here: you need to analyze the source mail system and understand what it has with the following parameters:

    • incoming and outgoing volume of SMTP traffic;
    • the number and total volume of mailboxes;
    • number of end users;
    • customer location: they can connect from the inside and outside the network, from domain or non-domain machines;
    • client connection protocols and client versions (MacOS client, Outlook Anywhere, POP3, IMAP, ActiveSync);
    • current configuration of the mail system:
      - the number of SMTP domains of the organization;
      - the number of distribution groups;
      - the presence of large boxes (from 20 GB);
      - availability of service boxes (for 1C, scanners, mailings);
      - mass mailings.

    Based on this information, we will think through the sizing and architecture of the new mail system.

    In one of the projects, the client forgot to talk about the fact that their marketing sends out millions of letters daily. As a result, the new system was scrapped without taking this load into account. When the mailbox from which the mass mailings went moved to the new system, the infrastructure of the new mail system “lay down”. I had to do resizing the system on the go. Fortunately, everything worked on virtualization and quickly adding resources was not difficult.


    Mail system architecture


    The choice of MS Exchange architecture will depend on availability requirements. There are two options:

    Stand alone. All mailboxes are located on one server. This option is not about high availability, but about low cost. There is no backup at the application level. If there is no redundancy at other levels (for example, virtualization), then Exchange will be unavailable during a failure.
    Such an architecture is suitable if you have few mailboxes and you are happy with recovery from backup.

    High availabilityAll roles of the mail system are duplicated. MailBox servers (MBX in the diagram) are added to the Database Availability Group (DAG). If one of the servers fails, the mail databases will move to the backup ones. The end user will not notice anything. This scheme can also be implemented within two data centers. Then the mail system will not be afraid of the failure of the whole data center.

    This architecture is for those companies for which simple is unacceptable. Most often these are large companies.


    HA circuit.

    Choice of antispam / antivirus solutions


    From my experience, I will say that large companies choose something like Kaspersky Mail Security. Small projects usually use built-in anti-virus and anti-spam solutions. They may not be as convenient or functional as third-party solutions, but they also perform their task well. Nobody really complained yet).

    Sizing the mail system


    The question is not worth it if the new system is a complete clone of the old one and we do not plan to change anything in it. For other cases, you will have to calculate the resources. MS has a tool (actually just an excel-plate with a bunch of parameters :)), with which you can calculate the amount of resources for installing Exchange - Microsoft Exchange Sizing Calculator . I must say right away that the tool is not intuitive and will take time to figure out, but this is a good option if you have no experience in sizing such projects.

    When calculating, do not forget to make an amendment to the fact that the mail system will backup, which means that the backup speed will also depend on the type of drives used. If you plan to use an antivirus that will check the database online, then it is more logical to choose SAS disks, but, of course, the choice of the type of disks should be based on the analysis of the real load on the system.
    Since migration does not occur simultaneously, especially for large companies, it is necessary to provide for the possibility of scaling the infrastructure for mail (in one project, during the migration, the number of users managed to grow by 2 times - it was 1000, it became 2000). If virtual resources are used for the system, then this is easier to do.

    Migration method


    The method of migration is determined by the following points: the size of the mail system, the time frame, whether you can afford the simple and labor costs that you are ready to go.

    With the over-migration, the entire mail system is transferred to the new site entirely in one iteration. This option can be considered if you have a small mail system (up to 500 GB) and you agree to a simple one from a few hours. Migration itself will be quick: if you successfully plan techno, you can move over the weekend or even faster, with minimal inconvenience to the business.

    In coexistence scriptthe mail system is gradually being transferred to a new site without downtime. At the same time, the source and target mail systems for some time simultaneously live on two sites: some users are already working in the new system, and some are in the old one. Such migration is suitable for any volumes, but the terms, labor costs, and costs increase, since the data is transferred in parts and the number of approvals and other bureaucracy increases. Technically, this is a more complex option, you need a certain qualification of admins.

    Migration plan, instructions, regulations


    Once we have decided on everything, we fix the order of actions in terms of migration . We prescribe all the technical details of migration in it:

    • architecture of the source and destination systems;
    • technical windows and downtime;
    • the actual migration procedure.

    If there are many participants in the project, then we prescribe the procedures for administrative interaction and areas of responsibility . It is not necessary that this be an official paper with a signature and stamp on each page. You can simply agree in a letter on who is responsible for what, how interaction with third parties is built (DNS hoster, cloud provider), etc.

    Do not forget about end users: we warn them about the date of switching to a new mail system, we prepare instructionsor a whole FAQ on connecting to a new mail system and what to do if something doesn’t work. We use the same algorithm for technical support. No, this is not a formality. When several hundred or even thousands of employees at the same time do not know what to do, and start attacking technical support, which will also be out of touch, it will not be very fun.

    In one of the projects migrating from Office 365 to Exchange, there was the following situation. On the source system, users had two accounts - for logging on to the computer (AD-account) and for logging in to mail, in Office 365. After the migration, only one account should remain. There were about 600 users, so it was important to clearly convey to them which of the accounts to use in the new system.

    That's all. Ask questions in the comments. And all successful journeys.
    Tags:

    Also popular now: