How to Mitigate Against a Cloud Implementation Storm


Migrating to a new cloud service not only requires evaluating and finding the right cloud partner that meets your requirements, but also ensuring that your infrastructure and processes are ready to integrate with the new service.

A hasty or ill-prepared launch into a new cloud service could negatively impact your existing processes never mind absorb a lot of time, effort and cost to remediate if things don’t go well first time.

As with all IT implementations a cloud migration needs to meet the business goals and the best way to measure whether the business goals have been satisfied is to have a clear quality assurance delivery programme.

At ChallengeCurve we have compiled the 5 key areas for which a cloud migration programme team should consider to ensure a smooth transition to a cloud service:

5 Key Areas

Cloud Requirements

  • Is the cloud business case clearly defined and scoped?
  • Are the business benefits and ROI viable and achievable? How have they been validated?
  • Are the business requirements defined and complete? Are they succinct, unambiguous, traceable and verifiable?


Cloud Engagement Options

  • Have you investigated and compared the different cloud models?
  • Have you investigated vendors and their service maturity: reporting, capacity, change management, incident management, financial management, service level management?
  • Have you scoped and targeted your existing or new systems to be considered for cloud migration? Have you considered business criticality and the sensitivity of data to migrate?

Cloud Acceptance Criteria

  • Have you reviewed your current operation procedures and identified the points of integration with the cloud services?
  • Have you reviewed your existing SLA targets?
  • Have you defined a new enterprise wide SLA framework for the cloud services to work within?
  • Have you define the business acceptance criteria for the new or amended business processes supported by the target cloud services? How will the vendor demonstrate meeting these criteria?
  • Does your operational team have the right skills to maintain and operate the interfaces with the cloud service?

Cloud Contracts

  • Availability. What is the cloud uptime? What is in the cloud SLA?
  • SLA Penalty. What is the consequence for downtime?
  • Performance. What performance load can be supported?
  • Data Security. How secure is your data?
  • Cloud service usage. How are you charged for the cloud service?
  • Cloud termination. How do you get your data back out and how long will it take?
  • Service amendments. Can the vendor change their service post signed contract?

Cloud Acceptance Test

  • Have you identified the implementation stages to the cloud migration?
  • What data migration checks can be applied to each migration stage?
  • Have you defined a set of cloud service termination and exit tests? How will you extract your business data and processes from the cloud vendor on termination?
  • Have you create a migration test plan, prioritising test scenarios by business criticality and risk?


Summary – Critical Success Criteria

  • Senior management are committed to the delivery of the cloud service. They are involved throughout the implementation
  • Enterprise service levels and service operation manuals are updated incorporating the new cloud service. These are reissued to the appropriate help desk and service support teams with training
  • Business process guides are updated to clearly define responsibilities and handoffs between the organisation and the cloud service provider
  • Business and IT regression test suites are continually maintained with each change or cloud service update
  • Cloud exit tests are performed as part of the enterprise business continuity plan to ensure the company is mitigated against potential risks

Trying to Shift Left but Sliding Right?



Delivering high-quality code into production faster, cheaper and more efficiently has always been a primary objective of the software delivery process. Recent initiatives such as Shift Left, where the focus of testing effort is moved upstream closer to business design, has gained widespread popularity and adoption. However, for some organisations there has actually been a reverse trend where the User Acceptance Testing phase has increased in scope and size. How can this be? What are the circumstances behind this trend?


In this whitepaper we discuss the real situation in which many organisations find themselves and some techniques on how they can start to Shift Left.


Please contact if you would like a copy.


CEOs take note: “Is there a Code Cheat in your products?”

As featured on LinkedIn.


The recent Volkswagen’s emissions scandal when a “Code Cheat” was placed in the software of diesel cars has resulted in the departure of former CEO Martin Winterkorn, a 30% fall in VW’s share price and a criminal investigation. But it has also created an important precedent:


CEOs are ultimately accountable for the source code of their products.


The boards of major corporates are handsomely paid; they enjoy the perks and trappings of high office and are trusted by employees, shareholders and customers alike to create sustainable returns by providing products and services that meet consumer needs.


Corporate boards deal with strategic issues, shareholder meetings and 3 year plans so the world of bits and bytes in computer code is a long way from the boardroom. Computer code is “deep techie stuff” and has no place on the agenda of corporate board meetings – until now.


Martin Winterkorn denies any knowledge of wrongdoing on his part but ignorance is no excuse as he has found out to his cost. The incident at Volkswagen may have left other CEOs worrying if something similar could happen to them. If not, then they should be.


What could Martin Winterkorn have done differently to have quickly determined who was responsible for the “Code Cheat” within the fleet of diesel cars rolling off the production line? What would he now give to have had complete traceability of the source code – who specified the designs, who wrote the code, who tested it, who implemented it? If the proper processes were in place then this information should have been available to him within minutes so that he could have quickly found those responsible and taken the appropriate action. It is because he didn’t have this information that he had to assume the responsibility for this scandal and resign.


Perhaps if the lines of computer code were given the same scrutiny as the figures on the company ledger then this episode may not have happened? Every financial transaction that organisations conduct can be traced and tracked. Independent auditors scrutinise the books before signing off on company accounts so perhaps we need the same independent diligence for scrutinising a company’s software code?


Organisations often feel that investing in independent Quality Assurance and Testing is a costly overhead or a commodity service for which the lowest tender wins the contract. Given the VW incident many companies may now take a greater interest in the hygiene of their computer code – after all, a 30% fall in the share price and a class action lawsuit due to some errant computer code is going to make the agenda in most boardrooms.


The Changing Currency of Business Value


“Delivering value to the business” is not just the mantra of every IT Department – it is their raison d’etre. Yet often the Business may feel that their internal IT Department is too slow, often late or too expensive in delivering new systems and maintaining existing ones. Recent survey statistics on the amount of projects that end in failure confirm this [1]




Clearly, the Business feels that it is not getting value for money. There is a growing trend, known as Shadow IT, where the Business deliberately bypasses their internal IT department to engage directly with service suppliers in an effort to gain benefits more quickly. The provisioning of Cloud-based and “Software as a Service” models makes it very tempting for the Business to procure new applications. Yet often the IT department will end up having to manage the new service in terms of maintaining user access controls, backups of data, etc. It is too early for the demise of the IT department but there has been a loss of confidence and trust in the IT department’s ability to deliver business value.


What can the Business and IT do to address this perception? How can IT not only deliver more value to the business but also be seen to deliver more value?


This whitepaper examines why the quality of an end product or service often falls short of expectation and how the definition of business value changes currency at each delivery stage. This “value currency exchange” leaves the delivery open for loss of value to occur. The paper concludes with recommendations on how organisations can maximise the efficiency of their value currency exchange.


[1] Raconteur.


Please email for a copy of the white paper.

Time for a new QA framework?

Too often Quality Assurance has been seen as a drag to organisations – at best it’s a box ticking process that is a burden to complete and in the worse case scenario it stifles innovation and gets in the way of the real work. Time for QA to change?

We think so. We set up ChallengeCurve to enable organisations to embrace change and to be innovative by providing them with the right QA harness to confidently experiment and to try out new ideas.