Once the new hosting contract has been signed, procurement breathes a sigh of relief and IT catches its breath: now it’s getting critical, the systems want to be moved. Here, as so often, detailed and forward-looking planning is recommended, because only then will the transformation project be a success.
Moving your IT data center landscape from one provider to another is one of the most interesting challenges in IT infrastructure management. On the one hand, the project can be very large; on the other hand, you have – ideally – little practice at it. So it’s good to be prepared and, if necessary, to choose a partner with sufficient lead time.
The process
The transition project will always look a little different depending on the customer and provider, both in terms of content and timeline. Basically, however, the following phases can be distinguished:
- Project start
- Sandbox test
- Test-Moveover
- Production cutover
- Follow-up
Somewhat more detailed, here exemplary for a SAP 3 system landscape of medium criticality database size the renewed listing of the phases with contents and estimations:
- Start: 5 days effort (period 4 weeks): Kickoff, order WAN, set cutover date.
- Sandbox: 5 days effort (period 2 weeks): detailed process planning, takeover of first test systems
- Test: 5 days effort (period 4 weeks): Takeover of test landscape, test
- Production: 15 days effort (period 4 weeks): Preparation, optimization, execution of production move
- Follow-up: 5 days effort (period 1 week): Hypercare, execution, optimization
Please consider possible complexity drivers such as availability requirements, database size or complexity of the company. If you are facing such challenges, be sure to add appropriate allowances to the estimates made.
While the start of the project is quite easy to define, the same is not always true for the end of the project. The demarcation between go-live and production (and its optimization) is not always clear. Make sure that you define as clearly as possible in advance when the project is considered to be completed. On the one hand, this prevents IT from assuming operational responsibility too early, and on the other hand, the project has a clear framework within which it can operate. In this context, also clarify until when incidents and open points in the project will be taken up, and when these will fall under the responsibilities of operations.
Of course, it is possible to come to an amicable agreement here without haggling over individual hours, but transparent communication in advance considerably reduces the risk of scope creep.
The first steps
Normally, a transition project is preceded by an invitation to tender. Here, the pressure is often high to start with the first activities before the end of the tender. Be sure to have a signature on the new hosting contract (-swerk) before implementation begins. Many hosting partners generously offer to start the transition even before all details have been clarified on the basis of an LoI (Letter of Intent).
I strongly advise against this, because clarifying the details can, in the worst case, lead to the failure of the negotiations. Then you are sitting on a mountain of internal and external effort without a contract, and you may even already have part of your systems with the partner (and thus no more leverage in the negotiations, and hardly any retreat options). So you are welcome to plan already, but you should not implement until the signature is dry.
It is recommended that both the customer and the partner appoint a project manager, but only one of them takes overall responsibility. Once both are known, draft the basic project documents: goal and scope, organization, stakeholders, timeline and schedule. Once approved by the client (usually the CIO), this information forms the basis of the kickoff meeting. If the contact persons present there are not authorized to make decisions, the content presented should of course first be coordinated in each case.
A small tip: make sure you coordinate any potentially critical project content before the big meetings. A heated discussion about moving the production-critical self-developed print daemon to the second Linux server from the left robs you of time on the one hand, and weakens the project’s reputation with the audience on the other. So identify possible pitfalls, and take them in advance in a small circle. The kickoff is not a discussion meeting, but a presentation of the project content. Of course, you should still allow and take in any feedback.
The first operational office action (preferably even before kickoff) is the design of the future landscape and the ordering of the WAN connection. Deploying this will take several months, depending on the connectivity type, and is the overarching critical path for transition projects.
In this phase, you set the framework for the project before and after kickoff:
- Organization: where will key documents (project plan, incident list, open items, etc.) be stored, who will maintain them
- Documentation: clarify audit requirements
- Transfer type: migration export necessary? Filer or WAN?
- Resources: three partners involved (two hosting providers and the customer company)
- Testing: who should test in what detail, who creates test plans and keeps track of them
- Cutover: how much time is available for the productive cutover, initial scheduling
- non-SAP: do tools and know-how exist for the cutover?
The test run
Once all parties are aware of the project and have scheduled resources, the test run can begin. The test takeovers should take place as late as possible on the productive takeovers in order to check processes and tools used for usability and not to give the landscape the opportunity to move too far away from the test environment.
The timeline developed with the partners should be clearly communicated (especially in the case of changes) to allow the business units involved to schedule resources. Once the deadlines are confirmed (or at least unchallenged), implementation can begin. For critical resources in the project, tacit acceptance is not sufficient; here, proactively coordinate the planned deployment with affected employees and managers.
Normally, you start with any system (can also be the productive one) and perform a first sandbox run. This does not have to be consistent (offline), nor does it have to be fast. It is only important to test the planned procedure once. If the productive system is used, make sure that it does not communicate in the target after the test setup (lock all users, disable all batch jobs).
If this run was successful, the takeover of the non-productive systems can begin. The test periods are measured according to the requirements of the business units; SAP recommends a test period of 4 weeks for migrations.
Design the tests to be only as elaborate as necessary. Focus on communication processes (SAP Logon, Print, Up/Download, IDOC, PI, Files, ..) because these are most affected by the change. Clarify which test reports should run before and after the productive move (FI and CO are the focus here) and test how much time they need for these.
Cutover and the time after
In addition to the project plan, set up a detailed cutover plan that includes these times. Who has to do what and when? Which final activities must take place directly before the cutover, and which directly after? Which processes and functionalities need to be tested before the systems can be released to the customer again once the move has been completed? How and where are the test protocols stored?
Not to be forgotten is the question of fallback. It is important to consider
- At what points do you need to create fallback options (often a full backup)?
- How long will it take to implement the fallback scenario?
- When do you need to start in order to make the legacy system available again in the event of an emergency while the maintenance window is still open?
- Is there another point of no return in addition to the production deployment that requires a separate release?
- How long do you keep fallback scenarios?
- How long do you have to keep the last backup before the changeover (e.g. for revision reasons)?
In addition, think about your project members. Relocation projects often take place on weekends and outside office working hours. Especially in Germany, you should contact managers and the works council in good time to coordinate work schedules.
Following the cutover phase, including the go-live, a phase of more intensive support follows after the go-live to the specialist departments – the so-called hypercare phase. In this phase, customer inquiries are still answered by the project team, which is on heightened alert (often with on-call numbers) for this purpose. The line organization will support to be trained on-the-job by the project team during the first weeks of production operation. The hypercare phase typically ends 4-6 weeks after go-live. If a high number of serious errors occur, an RCA must be performed, which may lead to a project change. Theoretically, a redesign with delta implementation, test and mini-GoLive is also possible. In most cases, however, the system can be brought under control without such drastic measures.
Conclusion
When the system is finally accepted, the project ends. The system, the documentation and the support process are officially handed over to the line IT. The IT colleagues trained in advance in training sessions and on-the-job should now be able to support productive operations independently. Feedback on problems and potentials (lessons learned) recorded in status meetings in the meantime is now brought together and discussed with the team. The results are stored centrally to allow access to subsequent projects.
You have made it, time to celebrate success with the team (line and project). Even in the tightest project budget, there should be some money to exchange project anecdotes and future plans over an after-work black tea. That rounds off the project pleasantly, and facilitates the entrance for the next project.
A changeover with as few problems as possible,
