Deployment and cutover

The size of the task shutting down and upgrading our systems, transferring data to the new system before re-starting the systems and going live, cannot be underestimated. Our success was critical to New Zealand given that 80% of the Government’s income is collected by Inland Revenue. It was also critical to the reputation of the agency and the transformation programme.

Deployment was a workstream within core tax and social policy, the middlemen between the delivery team and the support team. Work on deployment began as soon as the scope had been agreed. This meant our deployment team had chance to familiarise themselves with the product characteristics, the data sources and size of the load and the overall complexity of the task, right from the start.

Business Transformation deployment plan

Deployment within our transformation comprised all activities required to implement the new solution into the Production environment and to ensure that the organisation was ready for the change. The deployment plan incorporated the deployment activities prepared by separate teams:

• Business deployment plan – the operation tasks to be completed by the organisation
• Heritage deployment plan – activities required to transition data out of our old systems
• FAST deployment – activities required to prepare our new service platform
• Digital ecosystem deployment plan - impacts and activities required within our digital channels.

Third parties

Cutover tasks weren’t restricted to the organisation or our main technical partner FAST but involved between 30 and 40 partners and supplier organisations, depending on the release, who all had a critical part to play over the cutover window.

We tested, and tested, then tested some more

We practised the cutover from our old to our new system multiple times and tested everything thoroughly. There were 3 formal mock go-lives. The first, a paper walkthrough, the second, a full system walkthrough during working hours (which could last up to 2 weeks) and finally, a full technical go-live in real time.

It didn’t stop there. Where we uncovered issues or complexity, we re-tested and ran mini mocks. Release 4, where we transitioned student loans and KiwiSaver data into our new platform, involved the most complex data. Here we ran 6 mini mock go-lives before the data reconciliation was accurate.

As a result of the groundwork and disciplines we had put in place, we were able to cut-over remotely for the April 2020 release, within 2 weeks of New Zealand going into its first COVID-19 lockdown. What made this possible, was that our deployment and cutover team were very well prepared and very clear about what was required of them.

Cutover issues resolution process

During cutover, any task which deviated from the master cutover plan, which could have had an impact on go-live was escalated to the cutover control centre. From there, there was a framework and process to follow which allowed the team to get back on track or manage the issue down the line.

This generally meant a core group getting together in a room to work through the issue. An unforeseen benefit of working remotely was the ability to network in a larger group of people through online meetings, thereby working through the issue faster.

While we opted to go-live remotely for our final 2 releases, the team missed the camaraderie of a tradition cutover, and the associated mountains of pizza and junk food that entailed.

Cutover window

For most technical programmes, cutover takes no more than 2, possibly 3 days, so this activity can happen over a weekend. With the complexity of our transformation, the cutover period was by necessity much longer, so we used public holidays to minimise the business hours our people and customers were unable to access the system. Our cutover windows varied from between 2 and 7 days (for Release 3), where we took advantage of Easter and ANZAC Day which fell in the same week that year.

While we planned the target date for go-live at an early stage, we did not know the duration of the cutover outage window for certain until after our third mock go-live. So we had to decide whether to keep the dates under wraps until we could offer our partners and customers certainty, or share the dates sooner and be prepared to change the message. We opted for transparency and only once had to recommunicate the dates.

Supporting our customers

During the outage window, all of Inland Revenue’s systems were unavailable so even minimising the number of business days we were closed (to a maximum of 3), we were conscious of putting additional pressure on our customers.

Cutover involved closing all digital and voice channels (including myIR), front-of-house and required changes to payment dates for beneficiaries. Businesses were unable to file during the outage window, so the communication effort to make sure they were aware was significant.

Any changes to the treatment of customers around compliance was decided by the organisation, with communication managed by the programme.

Full details of the cutover process can be found in the Integrated Deployment Approach and Plan.