Share This:


Here are some lessons learned we have collected from the many upgrades as well as consolidation projects using Alderstone CMT and our methodology. A big thank you to the team at Alderstone Consulting for helping me put this together. Although these may seem like common sense you will be surprised how many a projects still suffer because of shortcomings in the following areas:


1. Environment readiness

  • Ensure the customer architects have an understanding of the architecture requirements and they have agreed to the architecture.

  • Understand document/process for hardware ordering and procurement well in advance.

  • Ensure agreement from Customer Security team – DB access queries have caught us even after it has been ‘agreed’ during the sales cycle.

  • When environments are ready, install CMT and test as soon as possible to reveal any issues that may require support from other areas and often can take extended period of time to resolve.

  • Invest time explaining the process and walk through with Operations and DBAs to ensure support throughout the project.


2. Project Planning and resourcing

  • Share and walkthrough Best practice Methodology and template project plans.

  • Ideal set up – Strong technical PM, Technical lead, Test Manager (involved early).

  • Even where data migration resources are Alderstone or Partners, it is good practice to get the Tech Lead and any others at least ‘aware’ of how CMT works, they will then be careful around data changes, keeping gold builds clean etc.

  • Emulated Cutovers (ECs) are a key factor of success, involving the whole team, emulating as much of the cutover as possible. ECs have revealed countless issues when the project could still deal with them rather than when it was too late.

  • As soon as it is available share the project plan with all of the project team, discuss and ensure everyone understands the criticality of their role.

  • Regular project meetings, even if just 30 minutes allow people to engage and query, removes the assumption that “someone else is dealing with that”.


3. Testing

  • Test plans produced early and reviewed by ALL.

  • Unit test, System test, Integration test and UAT must ALL use the test plans.

  • Reporting of issues should be structured and repeatable.

  • Triage team review the defect, ensure it is logged with right level of detail and has steps to reproduce, before considering where it should be assigned, rather than just assigning to Data team.

  • Detailed testing in UAT reduces issues after go live


4. Customisations & Process

  • Spend time with Customer Champions/SME to understand what has been changed within the ITSM system, compile the documentation (where available).

  • Review the current solution from a business perspective, how many of the legacy customisations are still needed by the business using the latest ITSM (recent project 112 “must have” customisations were reduced to 16 in a ITSM 9.1 workshop).

  • CMT will help discover what data customisations have been missed, but BMC Migrator and 3 way reconciliation will help the Customisations team identify, package and move all the required customisations. Use the right tool.

  • Integrations commonly need additional forms and data, ensure these are captured, impact assessed and documented rather than left as “it’s with the integrations team”


5. User Involvement

  • Exposing the “to be” system to the end users with their data as early in the project reaps great benefits, they can visualise new 9.1 processes easier, they will accept better practices and they will push back less on change.

  • Create a Sandpit environment with latest version and Customer data as soon as possible within the project. Use this a s a reference throughout the project.

  • Ensure users are aware and using the agreed test scripts so they can help the test team refine them where “not applicable to the business”.

  • Ensure all parties are involved, including regional representatives that may not have been considered.


6. Go Live

  • Practice the cutover plan during EC’s so there are no surprises during Cutover

  • Have someone other than the technical team running the cutover, managing the Bridge, updating the stakeholders, chasing up issues. That person needs to be fresh when others aren’t, on longer cutovers have people in shifts.

  • Consider a mgmt. bridge and a technical bridge to ensure Mgmt/Stakeholders do not derail technical progress.


7. Early Life Support

  • Structure your ELS in the same was as testing, Triage and prioritise issues, ensure they are reproducible, where possible keep a running copy of the old system to stop issues that have always worked like this.

  • The Test team are ideal ELS 1st line, they know the new system and they may have seen similar queries when they were starting.



For additional technical information on our methodology please get in touch with us. Our team are very happy to walk you through key activities and share our project plan with the above points incorporated to ensure you're next Remedy ITSM upgrade is a success.