Moving IT takes planning.
Moving single pieces of software and standard on-premise servers are not difficult to move to the Cloud, however, problems arise when they are integrated within a business and its processes. It adds a layer of complexity that is not always talked about. Why is this? In isolation, most technologies can be hosted in some form of Cloud Server or some Cloud Services. It is the ease of compatibility which ends the moment those platforms are integrated with other systems.
What are the main issues?
To put it plainly, communication and experience. The reason is that the responsibility cannot always be clearly defined between multiple parties. When moving a single service from an on-premise system up to a Cloud system, multiple parties are often required to communicate and work with one another, some of whom may not have been involved in that particular integration in the beginning. So, it really is dependent on unpicking the legacy system apart, separating out the various layers of technology, but also determining the responsibility of which parts fall under each company’s jurisdiction after they have moved into a Cloud platform.
Here’s an example…
A Local Exchange Server on its own can easily be moved to 365 (as in another Cloud Service or to Google). Complications arise when trying to move that server when the incumbent IT provider doesn’t realise that email server was also responsible for all of the scanners on site (so all the scanners use that local exchange server to send emails). What happens then? The next morning users cannot scan anything and so blame the Cloud and brand it as “rubbish”. It is only because of bad planning that situations such as this occur.
And, another example…
You move the Exchange Server to 365, your new cloud emails work great, the boss has his emails on his iPhone and Outlook appears to be working fine for all members of staff. However, the next morning in addition to staff not being able to scan, they find they can’t email from their ERP (which might be SAP or Sage or In4 etc). The reason they’re unable to email from their ERP is because it relied on the Local Exchange Server, which is something that was simply overlooked, or not even considered before the move to the Cloud took place.
These are the pitfalls that most business encounter when moving to the Cloud. They occur not because the technology can’t be moved, but because IT companies are not paying close enough attention to the elements that rely on the technology you wish to move to the Cloud.
A well thought-out process is key
There needs to be a key contact within the organisation who is invested in the success of the project when moving to the Cloud. As many people as possible should be aware of the upcoming changes, they should also be consulted should there be any processes that only they are aware of. Once communication is established with relevant parties there needs to be a process of asking questions without reservation regarding processes that are related, however remotely, to IT systems.
We avoid technical language and focus on practical business operations and impacts. For instance, the example above could have been pre-empted by asking the question “how do you contact customers?” Every element of the IT system should be addressed with the questions “what are you doing”, followed by “how are you doing it?” It can be summed up as “what goes into your business and what goes out?”.
Another helpful and less abstract method is to take a look around the premises and ask questions regarding how and if pieces of hardware are used. For example, a scanner may be used directly with ERP software which would entail specific technical arrangements with cloud services. This process should also be used as an opportunity to challenge overlooked redundant arrangements. For example, printing invoices for the sole purpose of scanning and emailing them, when the process could have been performed entirely with software.
If you need help moving to the Cloud, please get in touch with us on 01733 577055.
