A little introduction

I have been working on a G Suite migration project for one organization for a while now. In the beginning of the project few months ago I sensed a problem would arise later on. That problem is about a long time co-existence setup.

You would ask why that is a problem? Well, I’ll start with their current communication and collaboration system… They are using Office 365, having integrated it with multiple third-party solutions and applications.  Among these third-party solutions are meeting room manager, and an SSO application.

When building the project plan and during the initial discussions, I made sure to stress that the long time co-existence scenario is a really bad idea. The customer initially wanted to have that long time setup because they have a semi-slow change process, which seemed little problematic at that time… In order to finalize the project plan and start with the initial phases of the project, we decided that we don’t want to spend much time trying to convince the customer about this, and to keep it to later.

Right now we are approaching the end of the project and we need to do an important configuration… The customer started to complain about the wasted licenses on his Office 365 subscription, and his need to utilize them, so we suggested to do changes in the structure of his accepted domains and mail flow on Office 365 and MX records. And that was our problem…

When we get to the final phases of the project we usually start removing the co-existence configuration to keep one system by the end of the project… The customer did not want to do that, they did not want to change the MX record or change anything in their Office 365 configuration… So we reached a situation where we cannot keep going in the project. We cannot move further in the project. The customer insisting on not doing these changes while asking for their requirements to be met!

What is the problem?

When we talk about a co-existence setup, we mean two completely different systems… A co-existence setup is meant to be a temporary solution during a specific period of the project. Once you make that a long time solution you risk facing all kinds of problems and errors. Starting from delivery issues, to bottle-neck and mail delay issues!

Having some problems during a project is an expected thing, however having many of these is something no one wants. When the management or stakeholders see the daily reports and escalations of incidents and problems, they will start questioning the project and the product of that project…  And of course will put the consultant and solution provider in a bad place where people think they are unable to solve the problem!

Summary?

1. Co-existence scenarios are really great to make you initiate a project smoothly.
2. When a co-existence scenario go longer than intended it start becoming a problem by itself!
3. It is important to make sure the customer understands that co-existence scenarios can create problems if used for long time.
4. It is important also to make sure than all the configuration for a co-existence scenario are reversible easily.
5. As long as you have a co-existence scenario active in a project, the project will never close until removing that scenario.
6. Once you have no need for a co-existence scenario it should be removed immediately.
7. Co-existence scenarios are never intended to meet full functionality of a system or environment.
8. Before implementing a co-existence scenario, the customer must know exactly what problems to expect.
9. A co-existence scenario means you do strange, non-default, non-practical configuration on your systems.
10. A co-existence scenario can have bad effects on other aspect of your applications and environment.

I believe the above are the important points that must be considered… I’ll be updating the article with more content for sure in the future!