If your business is planning a move from Lotus Notes or HCL Domino to Microsoft 365, this is the guide to start with. It is written for small and mid-sized companies, not for enterprise systems integrators, so it assumes you may have limited internal IT, patchy documentation, and a few Domino workflows that nobody fully owns anymore. That is the normal starting point, not a failure, and a good plan is built around that reality rather than pretending it away.
A successful Lotus Notes to Office 365 migration is not a single mailbox copy. Email is usually the easy part. The work that decides whether the project goes smoothly is understanding everything else Domino quietly does, planning the move around your business, preparing your people for the change, and deciding who runs the new environment afterwards. This guide walks through the full path in plain language, with a realistic timeline, the issues that catch teams out, and the decisions that matter most.
The most common and most expensive mistake is choosing migration software or setting a go-live date before anyone has mapped what Domino is actually being used for. Tools are easy to buy and easy to demo. Knowing precisely what you are moving is the hard, valuable part, and it is what keeps a project from stalling halfway through when an unexpected dependency surfaces.
From the outside, Domino can look like just an email system. Inside a real business, it often also holds document storage, shared databases, approval workflows, archives, and custom applications that were built years ago and never replaced. Some of those applications may be quietly load-bearing, meaning a department cannot do its job without them, even if nobody has thought about them in years. A good migration begins by making that invisible layer visible before a single mailbox moves.
Your assessment should produce a simple inventory of:
For every custom application, you also want an early view of its fate: retire it, replace it, or rebuild it. If you cannot describe what an application does and who relies on it, that is the first gap to close, and it is exactly where an experienced partner earns their keep during discovery.
Complete the inventory above and make the early retire, replace, or rebuild call for each application. This single step is what lets you scope timeline, cost, and risk realistically, and it is the foundation everything else rests on. A migration scoped on assumptions almost always runs over on both time and budget, because the surprises surface at the worst possible moment, mid-project.
For most SMBs, the choice comes down to how much fidelity you need and how you weigh speed against completeness:
Decide what data you genuinely cannot leave behind before you commit to any tool, and write that down. That "minimum acceptable fidelity" prevents you from either overpaying for capability you do not need or, worse, discovering after cutover that something important was dropped.
Make sure the data has somewhere to land. Confirm your custom domains are validated inside the Microsoft 365 tenant, create and license each user's mailbox, and confirm archive capacity if you are moving archives. A tool running perfectly against a destination that is not ready is one of the most common causes of failed early batches.
Because a migration temporarily widens who has access to what, set your security baseline at the same time rather than treating it as a later task. Enable multi-factor authentication, put sensible access policies in place, and apply least-privilege permissions from day one. Starting secure is far cheaper than retrofitting security after the fact, and it means the new environment is defensible from the moment people start using it.
Unless you are small enough to move everyone in a single weekend, you will run Domino and Microsoft 365 side by side for a period. Coexistence is what keeps the business functioning during that window, and it rests on three pillars:
Calendar visibility is almost always the hardest to configure, because it requires the two systems to answer each other's scheduling questions in real time. Plan it early rather than discovering the gap once people are already split across platforms.
Move a representative pilot group of roughly 10 to 20 people first. Choose deliberately, including a few executives, some heavy calendar users, and at least one shared-mailbox owner, because these are the people most likely to surface problems. Before you move anyone else, confirm that mail, folders, and item counts match the source, that delegated access still works, and that search indexing and mobile sync behave as expected.
The pilot is where you validate your assumptions cheaply. Every issue you find and document here is one you will not be firefighting across the whole company later, so treat the pilot as a genuine gate, not a formality.
Group the remaining users by department or office and move them in waves rather than in one high-risk "big bang" cutover. Phased migration keeps disruption contained, gives your support team a manageable number of people to help at once, and leaves you with a clean rollback position at every stage.
For each wave, run the transfer, monitor closely for errors, and then run a final delta sync to capture anything created after the first pass, so nothing that arrived mid-migration is lost. Prioritise simpler departments first to build momentum and confidence before tackling the more complex business units.
Standard tools can report success while quietly leaving legacy quirks behind, and those quirks are what generate the frustrated help desk calls after cutover. Plan for these known issues rather than being surprised by them:
The fix is a consistent pattern: identify these items during the assessment, remediate them at the source before migrating, re-run a delta sync, and document any remaining exceptions so your support desk knows what to expect and how to respond.
Once mail has moved, resolve the custom applications. Retire what is no longer needed, replace simple workflows with tools such as SharePoint, Power Platform, or Teams, and rebuild the genuinely business-critical applications that cannot be replaced safely off the shelf. Rebuilding takes longer than moving mailboxes, so it usually runs on a parallel track rather than holding up the email migration.
Only once the applications are handled can you set a firm shutdown date for the old Domino servers and stop paying to keep them alive. Leaving them running "just in case" is how businesses end up funding legacy hardware years after they thought they had left it behind.
This guide focuses on the Microsoft 365 path in depth, but the same planning logic applies if you choose Google Workspace instead. The destination matters, but the question underneath it matters more: who will manage, secure, and support the new environment once the migration is done?
Every environment is different, but a typical SMB project follows this shape:
A simple, mail-only move can be considerably faster. An application-heavy environment with dozens of custom databases can run several months longer, largely on the application track. The four variables that move the timeline most are the number of custom applications, the state and cleanliness of your data, your compliance and archive requirements, and how much change your staff can absorb at once.
Ready to scope your move? Contact Cortavo for a low-risk migration plan.
A migration can be technically flawless and still feel like a failure if people do not know where their email, files, calendars, contacts, and workflows now live. Change is unsettling, and a workforce that feels lost will flood your help desk, invent their own workarounds, and quietly resent the whole project.
Budget real time for adoption. Communicate early and often about what is changing and when. Provide short, practical reference guides for the handful of things people do every day, such as finding their calendar, sharing a file, or accessing a shared mailbox. Staff a visible support window around each cutover so questions get answered quickly. This is far cheaper than the productivity hit and goodwill damage of a confused workforce, and it is the difference between a migration people tolerate and one they actually appreciate.
Migration gets you off the old platform. It does not, on its own, give you a secure, well-run environment that stays that way. Someone still has to manage users, apply security updates, run backups, control access, and keep improving things as your needs change. Without that, a freshly migrated environment slowly drifts back toward the same unmanaged, key-person-dependent state you were trying to escape, just on newer software.
For most SMBs this is where a managed IT partner matters most. The migration is a project with an end date. Running the environment well is an ongoing responsibility, and deciding who owns it is arguably the single most important decision in the whole exercise. A migration that is handed back to an already-stretched internal team the morning after cutover is only half a solution.
If you want a scoped migration plan that covers mail, coexistence, applications, user adoption, and the day-two operating model, contact Cortavo.
You start with an assessment of everything Domino is doing, not with a tool. From there you choose a migration approach, prepare and secure the Microsoft 365 tenant, plan coexistence so both systems keep working during the transition, pilot with a small representative group, migrate the rest in phases with delta syncs, and finally resolve the custom applications so the old servers can be retired. The technical steps are well understood and repeatable. The discipline that makes the difference is scoping the full footprint up front and planning deliberately for user adoption and day-two support.
A basic, mail-only move for a small team can take a few weeks. A typical SMB project runs roughly eight to twelve weeks end to end, and application-heavy environments with many custom databases can take longer, mostly on the application rebuild track. The biggest timeline drivers are the number of custom applications, the cleanliness of your data, compliance and archive requirements, and how much change management your staff need. A pilot early in the project gives you a much more accurate estimate for the full rollout.
Cost depends on the number of users and mailboxes, the volume of archives, how many custom applications need rebuilding, the level of training required, and whether you want ongoing support afterwards. Email migration alone is the smallest part of the budget. Application modernisation and day-two management are usually the larger and more variable line items, which is why a scoped assessment gives a far more useful number than any generic estimate. Framing the spend against the cost of downtime and the hidden cost of staying put usually makes the business case clearer.
Every custom application should be sorted into one of three buckets. Retire it if it is no longer needed, replace it with a modern tool such as SharePoint or Power Platform if a standard product now does the job, or rebuild it if it supports an important process and cannot be replaced safely off the shelf. This is the part of the project that most often gets underestimated, because the applications are harder to untangle than email and frequently have no clear owner. Handling them properly is what allows you to finally switch off the old servers.
Yes, and for most businesses you should. Running the two side by side, known as coexistence, lets you move users in waves instead of attempting a single risky cutover. The key is configuring directory alignment, mail routing, and calendar free/busy visibility so staff can keep emailing and scheduling with each other across both platforms during the transition. Coexistence adds some setup effort up front, but it removes the enormous risk of trying to move an entire company overnight.
No. Email usually moves first because it is the most straightforward and highest-impact part, while applications are handled on a parallel or slightly later track because they take longer to retire, replace, or rebuild. What matters is that the applications are planned from the very start, so they are not forgotten and left quietly keeping your old Domino servers alive after the mailboxes have moved. Sequencing the two sensibly is part of a good migration plan.