Let's talk about the technical backend and types of CloudSuite implementations.
Some organizations are hesitant about a move to the cloud because they aren't in control of the underlying hardware or data center that they’re running. It feels like there's a bit of a risk in not managing and owning all the infrastructure. However, there's a false sense of security that can come with this attitude, because even organizations that have invested in a robust disaster recovery plans have discovered that they aren't as fail-safe as everybody thought. There's always a risk of a hardware failure or some system failure, meaning that you're still waiting for an IT vendor to come in and provide support. This could happen while replacing a failed NAS controller in your data center or supplying a software patch for something, so it's better to be safe than sorry.
There's always risk in keeping mission critical applications up and running. The way that organizations have typically managed that risk is by having a great team of people who are fast thinkers, great troubleshooters, and experts in the application. As the world moves on from legacy applications, that particular talent pool is going to be reduced as people retire. Making sure that you are staffed with the right skills to keep all these systems running will become more difficult until your system administrator finally retires and you have to find someone to fill their shoes. Not only that, but you'll have to worry about disaster recovery and security as well.
Bearing all of this in mine, cloud implementations can be divided up into three varieties. One is the kind where your project goes off the rails, you spend a lot of money, and you don't get to the other side. Obviously, that’s a risk that you want to try to avoid by planning, finding the right partner, and making sure you understand what you're about to take on, all while having a realistic budget. The second type is where you actually go through this opportunity that comes around every couple of decades, but you don't take advantage of it to clean up your master data or to rethink your GL or HR structure. If your implementation or migration will be an IT-driven project where you can't get the business to engage, you should probably wait. You need the business users to engage and for people to take advantage of this opportunity so that you can build your infrastructure with an eye toward the next 20-25 years.
Then there's a third variety, where you meander through the project and you get to the other side, but your users are demotivated by the end of it. That's the opposite of what you want. A successful CloudSuite project should have people excited that they can now do their job better – that they can do better quality work, making them feel empowered to keep exploring, expanding the functionality, and focusing on process improvement instead of transactional issues.
