Factors affecting Migration velocity

Factors affecting Migration velocity

After a lot of experience in the field I’ve tried to bring together a bunch of items to consider when embarking on a Microsoft transformation. This blog is really directed at the Migration side of such a project, however many items are shared with coexistence.


The list may seem quite large, but in actual fact there are plentiful more things to consider, so its certainly not comprehensive, consider it food for thought. These items comes from the perspective of a Single Domino Domain, Single forest single AD Domain. The moment you start considering items like Hybrid, Multiple O365 Tenants, Multiple domino domains, TLS with partner organisations, security (to name only a few) this list would double in size.




  • Hardware configuration & choice of hardware.
    Virtual / Physical, NAS/SAN. Sometimes crazy things can happen with old hardware. We recently had a case where an organisations domino directory was very unreliable on older disks because their view index’s took too long to update, therefore their environment produced erroneous and sporadic errors.
  • Exchange configuration.
    Throttling policies, retention periods, write performance into Exchange
  • Quality & type of Lotus Notes data
    Personal groups and encryption takes longer, bad data or corrupt data can cause issues. The more data you migrate the longer it will take, it’s an obvious statement but many companies decide to migrate all their data, then down the line start to realise this is actually not really needed and reduce the data to more reasonable amounts. Do you actually need data 4 years old, do you need that calendar appointment from last year? Many small items takes longer than fewer large items. Big folder structures take a very long time to migrate. Repeating Meetings items with lot’s of reschedules take long time.
  • Location of the data being migrated e.g. mail server or staging server
  • LAN/WAN/MAN speed including saturation and latency on the network
    Everything should be on the local LAN to perform a migration). Companies should take serious consideration to having a staging server to replicate the data local to the exchange and migration infrastructure to optimise throughput.
  • Software configuration and account configuration e.g. choosing the right accounts & locales to migrate with, consistent software, consistent and correct configuration.
  • Deployment of software to user’s machines in a timely fashion.
    Furthermore, the configuration of users machines plays a big role, for example; numerous times we have come across previous version of Outlook being installed manually to support a previous companies PST data file. Or simle the users have been accessing their home email through a personally installed Outlook client rather than through some kind of corporate SMS deployment.
  • Amount of hardware. More workers means more can be migrated at the same time, and the migration can deal with failures of a machine. You’d be surprised how many companies want to migrate unrealistic numbers of users on the hardware they are willing to provide.
  • Reliability of hardware
    g. if there is a catastrophe with one device, can we recover or can the other hardware take the strain?
  • Internet access – if you are migrating to O365, do you have a good enough pipe. Furthermore, users are then downloading their full OST & OAB at Monday 9am, do you have enough bandwidth for 1000 users on Monday morning doing this all at the same time if you’ve migrated 500Mb of data?
  • Access issues, Citrix, VPN, webex, conference calls, internet access, domino accounts, exchange accounts (e.g. if your being watch performing the migrations over webex and it fails can we continue?)
  • Permissions issues, domino access, Notes ID access, password reset access (e.g. if we need to reset a password on the night of the migration or gain elevated rights can we do so efficiently?)
  • DNS issues and tracing issues (e.g. can we communicate with the required servers to make routing changes, are those changes replicating to the mail servers efficiently?
  • MX issues – simply getting access to change or add the appropriate names onto the domains the organisation owns.
  • VPN, firewall, DMZ configurations. It is surprising how many companies are not able to configure the environment correctly.


Soft Limiting factors


  • Amount of time “Migration Engineer” is available so is still effective next working day
    If remediation activities are required these should be accounted for
  • Time at which the migration event is initiated, and estimating the completion time for entire wave, does this encroach on any migratee’s business hours in their local time zone.
  • Remediation time and complexity. If there are multiple issues do we have time to resolve them all?
  • Changes to schedules, can these be accommodated? (e.g. too many changes lead to errors) Many organisation feel that technology should be able to cope with all eventualities in schedule changes, unfortunately the biggest problem in this space is that it doesn’t account for user error.
  • Change control and testing. (e.g. have recently deployed changes been fully tested end to end)
  • Availability of quality experts in all technology areas to resolve any issues when they arise.


Single biggest factor preventing companies moving forward.


  • The challenge that every organisation faces is the quality of their directories and the remediation required to ensure directory synchronisation. This is always under estimated. Lotus Notes is far more forgiving with bad data than Exchange is, and now that you will be moving to an internet address only environment, many of those discrepancies which never appeared will now cause you pain. These are the high level items from a Notes to Exchange migration that an organisation needs to think about:
  • Do you have a field in domino which perfectly matches an attribute in all your AD objects?
  • Check for duplicated and/or missing Shortnames
  • Check for duplicated, missing or invalid Internet Addresses
  • Check for duplicated SMTP Addresses in Fullname Fields
  • Do all group & database documents have internet addresses?
  • Remediate duplicate accounts, where an admin might have a personal account and an admin account. Or exclude them by moving to a different OU.