Aussie IT firms share stories from migrating monoliths

By on

This article appeared in the June 2016 issue of CRN magazine.

Subscribe now

Aussie IT firms share stories from migrating monoliths

To call CRM or ERP a critical system somewhat understates its importance. At the core of most companies, a customer relationship management or an enterprise resource planning system is the beating heart that keeps the business trading day in, day out.

These systems tend to be large, complex beasts with many moving parts, complex inter-dependencies, and a grumpy disposition. Years of work tend to go into tuning and adapting these monolithic applications to suit the needs of the business. Change is rarely a simple matter. We’ve all heard the stories of big projects gone astray.

So how do you migrate one of these large, complex beasts? In a world demanding agility and ever-reducing IT costs, there are plenty of emerging alternatives to run ERP and CRM systems – from migrating them to cutting-edge infrastructure to choosing public cloud options. So how can resellers take on such high-risk projects and succeed?

CRN spoke to partners that have helped customers successfully migrate complex systems to new infrastructure, and dug out three case studies in how to do it well.

1. Moving to hyperconverged

Famous boot-maker Blundstone had just made a major foray into the US market, and turned to its IT supplier, Anderson Morgan, to help move to a set of ICT infrastructure that would support business growth into the future. Anderson Morgan partnered with hyper-converged player Simplivity to migrate Blundstone to a more modern infrastructure platform.

The existing Blundstone environment had grown organically – as you’d expect from a company founded in 1870, long before computers existed. “Blundstone is a very old company,” says Bjarke Pederson, chief executive of Andersen Morgan. “They had lots of legacy systems. Like any large organisation, there is always that additional piece of equipment or additional program hidden away over in the corner.” Many of Blundstone’s processes relied on manual handling and spreadsheets

While much of the Blundstone environment had been virtualised, there were still physical servers that needed to be converted to virtual to be hosted on Simplivity. The vendor worked closely with the Anderson Morgan team. “The Simplivity team were down for three visits,” says Pederson. “There was the initial planning discussion, the pre-flight checks, and then the installation itself.”

Taking advantage of the vendor’s experience helped Anderson Morgan to prepare well for the unexpected. “One of the big things that we learned was that the Simplivity engineers, obviously through experience, have a knack for seeing things ahead of time,” says Pederson. The migration plan included windows of time where experience told the team that something may go wrong, so there would be a buffer of time in that particular area.

“The biggest challenge you have with any of these things are the unknowns, and there will always be unknowns,” says Pederson.

“There’s quite an extensive and detailed process that our technical team will go through in conjunction with our partners,” says Scott Morris, Simplivity’s VP for Asia-Pacific and Japan. “Once the majority of that work is done, the setup and migration is easy.”

“It’s all about the planning,” he adds.

The careful planning and attention to detail meant the actual migration went smoothly, with the new systems taking over from the existing solutions. “There was an incident where a legacy system needed some very specialised software,” says Pederson. “It hadn’t been discovered in the pre-flight check, but we were still able to deal with it and get it included as part of the migration without affecting the timeline.”

From the start of planning to the completed migration, the move to new infrastructure was completed in about three months, while the actual cutover happened over a few days.

“As far as our customer was concerned, they saw nothing but a very smooth implementation with all timelines being met through the process,” says Pederson.

2. Moving to private cloud

Electrical engineering company Nilsen Group is another venerable Australian business with a rich history, having been established in 1916. The organisation had been running New Zealand-born ERP system Greentree for some nine years, and found itself in a familiar position: existing hardware was reaching the end of its warranty period and needed to be replaced. It was time to consider the options.

“We had to refresh most of our hardware server environment, and with a SAN it becomes a fairly expensive exercise,” says Jeff Milton, Nilsen Group CIO. “We were looking at a couple of hundred thousand dollars worth of capital, or moving to a consumption model where you can turn it all into opex.”

Nilsen spent time considering its options, including discussions with their own staff and the staff at their Greentree partner, Star Business Solutions. Trish Hall, chief executive of Star Business Solutions, tells CRN that having experience in migrating Greentree helped the team educate Nilsens on what worked and what didn’t. “It’s important to know what to do at appropriate points in time,” Hall says.

Nilsen ultimately chose to go with a private cloud option, hosted by Telstra, using a blade server dedicated to Nilsen’s use. Star Business Solutions helped Nilsen to ensure that the new environment would be adequate for hosting the Greentree system. The new environment was considerably more powerful than the existing on-site environment, which meant the migration went faster than expected.

Star Business Solutions used a standard process developed to migrate the Greentree system as a test phase first. “We migrate the Greentree ERP system over, get it all set up, and make sure it’s operating as required,” Hall says. “Then, when you go to do it in the production environment, it can be done in a matter of hours.” Most of the time taken is copying of data, according to Hall.

Milton says two things made the migration easier. Firstly, the monolithic nature of Greentree ERP meant it didn’t have lots of interfaces to other systems to worry about. “The more interfaced you are, the more problems you will have,” Milton adds. “It’s one of the reasons we went to Greentree in the first place. It’s all within one system.”

Secondly, Nilsen Group decided to virtualise the Greentree environment some years earlier, and this gave the team a lot of experience in what it takes to move an ERP system. “If you’re going to cloud, you’ve really got to virtualise first,” Milton says. “It’s really a two-step journey. The two-step journey makes it a much easier transition.”

One small pitfall of moving to cloud – Nilsen still uses fax to communicate with many if its suppliers, and with on-site gear it meant having a fax-modem device plugged into the system. “Telstra weren’t too keen on us walking into their data centre to plug in a fax-modem,” Milton says. “I’m always a big one for ‘day in the life’ testing, because it helps to flush out these sorts of issues.”

3. Divesting a business unit

As an ex-employee of big four consultancy PwC, management consultant Keith Townsend has worked on some of the largest SAP systems in the world. Townsend, who runs The CTO Advisor, tells CRN that the dream of simple, easy moves doesn’t quite pan out with large, complex environments.

A client of his was a multibillion-dollar manufacturer that used SAP to run its operations, making the system mission critical to the organisation. The client was a business unit that was divested from a larger organisation, and that meant de-coupling the SAP system from the parent organisation, and moving from their data centres to a co-location facility. The client also opted to consolidate multiple SAP instances into one system, and to do away with other ERP systems in the process.

Such a complex project took considerable planning. “When you’re talking about a multibillion-dollar organisation, you’re looking at a $120 million project,” Townsend says. Planning for the move started in mid-2013 and took until the middle of 2015 to complete.

“The SAP-recommended method is to re-install the app on the other end and do a data migration, so basically that’s what we did,” says Townsend. 

Yet despite the size and relative complexity of the project, the steps involved are much the same as for smaller environments. “We moved one environment a month, following the stages in the software development life cycle (SDLC) used by SAP,” says Townsend. That meant starting with sandbox, development, and test before moving on to more sensitive environments. “The most critical environments, QA and Prod, were moved last.”

“We were able to refine the migration process as we migrated each SDLC stage,” he says. “After each migration, we’d go through lessons learned, process improvement, and keep refining the process. It helped to reduce the risk significantly for later, more critical, migrations.”

Townsend also noted that if there were fewer SAP environments to move, the migration would have been completed much faster. “If there had only been Dev, QA, and Prod, we could have been done in a couple of months,” he says. The size and complexity of the customer environment contributed to the time taken to migrate, and Townsend believes this limits how fast you can move.

Plan ahead

There is a wealth of experience out there now about how to migrate complex systems, and it’s never been easier to do, thanks to virtualisation, modern infrastructure, and helpful tools. Solid plans based on previous experience keep the risk of the unknown as low as possible. Things will come up, but if you can avoid the majority of the known issues, then you’ll have time and resources on hand to deal with any new or novel issues that arise.

The road to success is paved with practice. A partner with plenty of practice helps keep customers’ risks low, and should help the client practice before attempting the big cut-over to the new system. The right partner will flush  out any unforeseen challenges, and get staff used to the new ways of working.

Testing is crucial, and the closer you can make the testing to the live experience post-move, the more issues that’ll get flushed out before the big day. The user experience after the move can be a big part of how the project’s success – or otherwise – will be perceived..  


Fail to plan and plan to fail  All our success stories are based on solid planning backed by experience. Spend the time working out what needs to be done, and get advice from someone who has done it before.

Experience matters Practice makes perfect, and partners with experience migrating systems can guide you away from the traps and pitfalls.

Test, test, & test again  You don’t know things are working correctly unless you test them, so make sure you test as much as you can before you hit the point of no return.

Virtualisation is your friend Moving systems from place to place is made much easier when they’re virtual. The process of making a system virtual helps you understand what moving it will be like, and frees you from the underlying hardware, removing one of the risks.

Got a news tip for our journalists? Share it with us anonymously here.
Copyright © CRN Australia. All rights reserved.

Most Read Articles

You must be a registered member of CRN to post a comment.
| Register

Log In

Username / Email:
  |  Forgot your password?