The purpose of this blog is to highlight some of the challenges you and your hosting provider may face when you move your IBM i (iSeries/AS400) applications to the cloud. Better to be foretold and forewarned to be prepared to move forward with few surprises.
Disclaimer: iSeries and AS400 are servers. IBM i is an operating system. I use these terms interchangeably to make it easier for folks to find what they are looking for on the web.
For a guy that promotes IBM cloud hosting, the last thing you would expect him to talk about are the problems he and his team encounter.
After all, moving to the cloud is simple, right? Well, it is in the sense that the IBM i environment is pretty much saved from your on premise server and restored to a hosted environment…
…Unless you encounter some of these issues that can cause delays.
Firewalls – Limited Skills, The Old And The Complex
Most hosting relies on users to connect to the hosting environment with VPN (Virtual Private Network) IPSec.
This is a very safe protocol that provides for fast user performance.
With that said, we can experience delays with firewall connectivity setup. Quite simply, we cannot progress with testing and using the hosted environment until we have the firewalls connected.
Frequently, the IBM i users moving to the cloud have limited to no in-house networking skill to setup firewalls. Their firewall consultants are busy and difficult to schedule. We have experienced delays from a few days to several weeks waiting for the availability of the skilled network engineer to be on hand for this setup.
This can take longer when it involves larger enterprises to review the security and protocol for this setup.
Occasionally we encounter users with older firewalls that do not support newer forms of encryption. This may require newer firewall technology, which may take weeks to months to assess, acquire, and setup internally before a prospective client can connect to our hosting resources.
Also, some firewalls are extremely complex and require highly skilled engineers that may only be available from the manufacturer. We have had cases that took 2 months or longer before the needed skill was accessible to complete this connectivity task.
Unreliable Backup Tape Media
When we first started to offer hosting years ago, we boasted that we could restore from any backup media, including QIC, 4 MM DAT, 8 MM, and ½ inch.
Well, those days are behind us.
Here’s why.
Non-LTO media is not reliable. They have an effective shelf life of 2-3 years. And, in many cases, users have been saving their systems onto unreliable media. They do not know it is unreliable because they do not test their tapes or their backups.
Then we get their tapes to restore and cannot read them because the media is unreliable.
What to do?
We rent or sell a compatible LTO tape drive to get a reliable backup tape that we can read. (And, once discovered, it may take up to 30 days to get the tape drive attached, schedule a backup to send to us and we have the schedule to restore it.)
So, if you are still using QIC, 4MM, 8MM or ½, be ready to get an LTO tape drive to generate reliable backup media that your hosting provider can read and restore.
Application Testing – The Unexpected And The Unknown
Once the prospective IBM i system has been restored, the next task is testing.
Some testing is straight-forward. For example, testing common processes, day-end and month-end routines, batch jobs, and print jobs. Also testing APIs (Application Interfaces, such as EDI, credit card processing, etc.). And testing desktops and peripherals.
Sure, we have testing recommendations, checklists, and templates to facilitate this process.
On the other hand, we do not know the application software. The client does.
And many times nuances of the software are taken for granted or have been forgotten.
For example, there are still many companies using fax that are unaware that faxing is not supported like it was on their legacy server. Specifically, newer IBM POWER servers do not have the slots to support comm cards. (The cost of an expansion chassis to support comm cards is VERY EXPENSIVE). Also, data centers charge cross-connect fees to bring an analogue line into the data center to support faxing.
All this means that if you want to do faxing, you will have to modify your applications software to use a web-based faxing service.
Here’s the rub. Many folks that fax do not tell us up front or, when we ask, are unaware because they do not do it very often. So, it gets overlooked.
Or, many are surprised at the cost of adapting their software to work with the web-based faxing solution.
What is the common outcome once the user understands they cannot fax like they used to? They decide that they will move ALL of their customers to just get emails …. and STOP faxing. (While this is where we end up, there is a lot of surprise and gnashing of teeth before we get there.)
Another common aspect we discover that is different than what we were originally told is system and data backup. While we are told at the beginning of a project how they “think” backup and retentions works, when we actually set up backup we commonly discover nuances and variations from what we were told. The most common reason is that the person who first told us about their backup process did not design the backup. (It was done 10-20 years ago and modified by someone else along the way.) Only when we go to set up the backup for the hosted system do we REALLY find out how the backup is supposed to work.
Version Upgrades
As you might expect, many prospective clients are moving to the cloud from legacy servers on un-supported and back-level versions of IBM i.
We often find it beneficial to test the application upgraded to the newer IBM i OS they want. This takes more time to prepare as there is research and preparation required to move a user’s system, say, from V5R4 to V7.3. Further the user needs to verify with their software provider to confirm their application software is V7.3 certified. (During this discovery process, the user may also find out unexpectedly that they will have to pay a software transfer fee.)
While it is ultimately best to test at the higher IBM i OS version before go live, it adds more time to the process and can cause delays to go live.
Summary
I have highlighted some of the most common challenges we encounter that can delay the migration from an on premise server to the cloud.
With this information, users can do a better job to prepare for the transition and SAVE money by not starting too soon without preparation for the challenges that can cause delays.
Need Help
If you think you want or need help, feel free to contact me. You can email me at blosey@source-data.com or call me at 714-593-0387.
Leave a Reply