Auditing a Migration Plan When Transferring from On Site to the Cloud
Have you ever audited a computer system’s migration plan when transferring it from on site to the cloud? Here are some recommendations to keep in mind based on lessons learned from migration practices:
- Clarify the work burden mitigation effort. Once cloud migration is complete, it is important to clarify what burden has been mitigated by the migration from on site to the cloud; for example, automatic scalability. If the company’s computer infrastructure system meets the requirements for automatic scaling service, it can enjoy not only the service, but also cost savings. A computer system, like many single physical servers and few virtual system environments, has to address mitigating the operational burden and full treatment.
- Verify there is no loss of security functions. A cloud vendor provides various security services; however, when transferring to a cloud environment, companies should examine whether any security services and circumstances that were addressed on site were lost or downgraded. For instance, if a company currently runs a laboratory-typed anti-virus sand boxing system, AI-based filtering system or industry-needed scoring system as a firewall, it should check whether the system can transfer onto the cloud vender’s service, as well as how it is priced.
- Find out the current application’s operation system and the infrastructure for the system, and determine whether it is possible to migrate them directly to a cloud environment. If the target application the enterprise is seeking to shift is a specialized legacy OS for which the cloud vendor doesn’t support service, it may need to migrate the legacy OS first.
- Finally, look at the risk mitigation procedure that will lead to the systems going live on the cloud. There are many existing layers, such as the internet connection layer, the OS infrastructure, middleware, application infrastructure, application server and application scheme. A company can’t help addressing them without upgrading them. Each layer requires its own upgrading activities and tests. It might be important to plan a step-by-step migration schedule. To migrate all at once is not always the best solution. In addition, when considering risk mitigation, Rollout and Rollback procedure should be designed by the user. The most risk-sensitive person is the user, and the user should be responsible to mitigate hazards.
Written by Katsumi Sakagawa, CISA, CRISC, IT consultant; excerpted from the ISACA Now blog