In order to support a key business requirement, it was determined we needed to have CRM 2007 from a technical standpoint. The primary factor was so that our sales force could enter data into CRM, instead of the ERP system. Our CRM 52 system was missing the functionality required for this integration which was primarily in the area of trade promotion management.
This caused us to look at an accelerated upgrade schedule for CRM 2007. Originally we planned on staying with CRM 52 for at least year before looking at upgrading again. Instead we would begin our upgrade project after only being live with CRM 52 for about six weeks.
To accomplish the upgrade we treated the project more like applying support packages rather than radically changing versions. Our initial research showed that the impact of going from CRM 52 to CRM 2007 should be minimal at most.
We started our project by first doing an initial cleanup of our sandbox. This involved synchronizing the sandbox to be in line with our development system.
Our next step was an upgrade of our sandbox. After this upgrade we did an evaluation of how broken the system was. We determined the areas we customized in CRM 52 did not require a huge amount of rework and we gave the green light to begin the development upgrade.
In order to keep the upgrade short we went with the split cycle strategy. The idea is that we would need five weeks to upgrade our landscape. The first week is spent doing upgrade for our development system. The second week is spent on upgrade adjustment work. The third week is spent on unit testing plus any adjustments as part of testing. At the end of the third week we conducted the “dress rehearsal” for production. By a dress rehearsal, we ran the downtime portion of the QA upgrade exactly as we intend to run the production upgrade. In fourth week we performed one final integration test and in our fifth week we conducted rollout sessions with power users.
If you noticed we did not use or build an emergency system in this case. Due to short time where QA would be unavailable, we opted for emergency changes in production during this period. I would recommend an emergency system if you plan on having a longer transition period between QA and Production, and also prefer to have a safety net.
During the upgrade project we notified users through a series of communications leading up to the actual production downtime and subsequent production Go Live. We provided simulations and training scripts for CRM 2007 via training management software that we own.
The first thing we learned during this process is that the non-downtime prepare was a lot longer due to the dual stack nature of the landscape. Our basis group added a few more days into the prepare cycle in order to meet this requirement.
Next we dealt with security. This came up very early as you need to have proper access to use the system. We found out that none of our end-user roles needed adjustment and only the configuration role needed adjustment. The primary change was to give access to the new web based configuration tool.
We normally make one “modification” to the system in order to support our security requirements. We had to adjust the crm_logon ICF node, again to support our logon procedure. However this only takes about five minutes to restore our settings.
The major portion of our remaining work involved adjusting the UI screens. We wanted to go to the editable overview screens. This meant not only configuring the new editable screens, but re-adjusting the overview pages. We deleted the old overview configuration, and then copied the standard back to our custom configuration.
The major difference for our users between CRM 52 and CRM 2007 is mainly in navigation and some slight differences in screen layout. We decided to start all our users on a fresh slate, by deleting all their personalization from the last release. Our goal was to have everyone use the “NOVA” theme. We don’t have a graphic designer or the resources in house to create a custom theme, so thus we stuck to the SAP standard.
Change Management/Training Issues
We spent a significant time working on updating the training materials. The two driving factors were because of navigation changes in the system and going to the new “NOVA” theme as our default. We also had to change the “hyperlink” to our online training server, to point to a new location. This was important since our users have taken advantage of our documentation being one click away when using the system since we went to CRM 52.
The day before the upgrade we ran the middleware re-organization job at a setting of “zero” days. The idea was that once the system was “taken down” for use we would need to clear out the middleware and BW queues and we wanted to minimize the downtime. During the day of the upgrade we ran this job several times to minimize the actual time to run once the system was taken away from the end-users.
We were finished with the actual upgrade on day one(partial day) and most of day two was spent applying the support stack, fixing some oracle issues, applying reconciliation transports and then running the SGEN. On day three we focused on verifying system build, middleware connectivity, and load balancing. We were actually able to finish early on day three and hand over the system approximately 16 hours earlier than expected.
Go Live/Production Support feedback
The general feedback from our users has been positive. Most of the questions we received post go live have surrounded use of the system, rather than an actual system error.
The real work for our CRM initiatives now is just starting. The upgrade was just the foundation to allow us to relaunch our CRM business processes and system.