As the end of support for SAP ECC looms, the option of migrating to SAP…
SAP technical implementation is incredibly complex. In SAP implementations, upgrades and migrations, your team is taking a massive, interconnected and custom-built system that serves your entire organization, and transforming it into a new (and hopefully better) system — while your business is running. A single mistake could harm productivity, create security holes, or even cause an outage.
The SAP technical project implementation process is designed to prevent that mistake from happening. With careful planning, frequent testing and many, many, iterations, your technical team can ensure a smooth transition to a system that supports your business needs and performance requirements.
SAP Implementation Process: Phase 1 — Onsite Initiation. The technical portion of the SAP implementation process starts after the project has been scoped, and certain functional work has already begun. In the onsite initiation, the technical team sits down with key project members and stakeholders to go over the project, and make sure all the pieces are in place.
A good technical partner will ask a lot of questions about connectivity during this SAP implementation phase, including:
- Who needs to access the system?
- How are people going to access the system?
- Are there going to be third parties or offshore partners accessing it through a VPN?
- Do you connect to external resources, such as a filesharing or content management system?
- What tax system connects to your SAP environment?
- Do you have banking partners that you exchange info with regularly?
These questions are necessary, because the people who made the decisions on the original SAP implementation project plan don’t deal with day-to-day support. They’ll ask questions about licensing and functional capabilities, but they’ll usually miss some external resource or legacy connection. The technical provider may need to slam on the brakes and make sure the SAP implementation process connects with all necessary systems and supports all stakeholders before things go any further.
SAP Implementation Process: Phase 2 — Data Center and Network Startup
The data center and network startup phase is generally only applicable when the SAP technical partner is hosting, or configuring new hardware for the client, not if the client has their own hardware. In this SAP implementation phase, the technical partner will determine how much compute the servers need, and build a virtual private cloud to host the customer’s environment.
Network engineers from the technical partner will work with the customer to build a VLAN — a network that connects the customer’s location and their SAP cloud hosting environment into a single unit. If the customer is doing disaster recovery, the provider will also link the primary (production) environment to the data center site.
SAP Implementation Process: Phase 3 — SAP General Activities
By this point in the SAP implementation process, we’ve reviewed the scope, added in any missing pieces, and built the network and servers. Are we ready to start the SAP migration? Not quite — there’s some groundwork to lay and cleanup to do before we can begin in earnest.
The partner will have to obtain some credentials, including the OSS ID — an ID at SAP tied to the end customer. This allows them to obtain the software the customer has purchased, and to log messages at SAP on behalf of the customer. They’ll also have to obtain the Operating System User ID, an SAP-level account the SAP Basis admins need to install software, apply patches, and perform other needed work in the SAP implementation process. The sap technical project implementation team will also do other preliminary work, such as downloading necessary software from SAP.
SAP Implementation Process: Phase 4 — Sandbox Migration
The later SAP implementation phases form an iterative migration process. The sandbox phase is the start of this process, where the technical implementation team can iron out big problems in a low-stakes environment.
In a sandbox migration, the team performs a test migration representing the core landscape, without the ancillary systems identified in Phase 1. Essentially, they’re making sure no one overlooked major problems — for example, they want to verify the system is patched to the right level, and prepared for upgrade. They’re checking to make sure there’s enough disk space, and that no one else is actually taking up the resources they need. By ironing out any major problems now, they can make sure that the SAP implementation process doesn’t run into any major problems later on.
SAP Implementation Process: Phase 5 — DEV Migration
The DEV Migration takes the lessons learned in the Sandbox Migration, and takes everything to the next level. Generally, it’s more complex — you’ll connect non-SAP systems, for example, to make sure they work as designed in the SAP implementation project plan. You may have to iron out new issues, such as network connectivity problems, or broken integration with third parties or customers.
You’ll also record how long each step of the SAP implementation process takes — data that you’ll need to create a timeline for the actual production migration and go-live.
SAP Implementation Process: Phase 6 — Quality Assurance Migration
Think of quality assurance as the dress rehearsal. You take your experience from DEV, perfect the process and do another run through, with the goal of perfecting the process. Quality assurance should be run as much like the production migration as possible, and your team should time each phase to set a reliable schedule for the main event.
Depending on the needs of the client, there may be an extra stage of the SAP implementation process called the mock iteration — we’ll call it phase 6.5. Up to this point, the test migrations have mostly used dummy data, which may be automatically provisioned by a tool like SAP TDMS. This lets them mimic the migration process while minimizing risk to sensitive data. However, businesses with really large landscapes may want to perform an extra SAP practice migration, using real system data, with additional safeguards to protect it during the process. This will allow for more accurate timing estimates during the production migration.
SAP Implementation Process: Phase 7 — PRD Migration
PRD or production migration is the final phase, culminating in go-live. Over the weekend, the technical partner will migrate the landscape and roll over to the new system. This is where all the timing work comes in handy. Because the technical partner knows how long the migration will take, they can time it so that rollover occurs at a point where it will minimize disruption — for example, late on a Sunday evening. The whole migration process usually takes around 48 hours, and the SAP team will need to be on duty the whole time, to perform each sequential step and make sure nothing goes wrong.
The SAP Implementation Process With Disaster Recovery
Once the production migration is complete, the system is ready for go-live — the migration team turns things over to the ongoing SAP Basis support team, who handles any post-migration tuning required. However, if the customer is setting up cloud disaster recovery services, it’s generally a good idea to synchronize production with DR and perform tests of the DR environment immediately afterwards. This should be included in the SAP implementation project plan.
SAP Technical Project Implementation is All About Attention to Detail
As you can see, the SAP implementation process is designed to eliminate risk and uncertainty. Everything is rehearsed, refined and rehearsed again, so there are no surprises when it’s time to migrate production. It’s crucial to choose a technical team with the experience and attention to detail to make sure everything goes smoothly at go-live.
Contact us to learn how Symmetry can help.