The 5 components of Cloud migration

When a customer is looking to migrate from Splunk on premise to Splunk cloud it presents an ideal opportunity to take a holistic view of the platform, not just from a technical standpoint, but also how it is used within the business, and the value the platform should be delivering. It is ill advised to simply “lift and shift” what already exists without taking the opportunity to review what is needed from the platform, and the broader implications of operating the platform from the cloud. When migrating, for example, applications to Splunk cloud it is a great time to examine who uses them, what they are used for and whether they can be improved or updated. Similarly, the move to cloud is a good opportunity to review the overall operating model of the platform. In this blog, we highlight 5 key areas customers can look at, to ensure a successful migration of their operational monitoring capability.

Business Objectives

The migration period presents an ideal opportunity to take a step back and review the existing setup and its core purpose. With any monitoring tool there is always the risk of user and process creep. Additionally, ad hoc elements may have been introduced over time without being reviewed or utilised, yet they remain in the system consuming space and processing power. Therefore, it is an excellent time to evaluate what is actually necessary and required from the platform.

Since analysts and administrators are the primary users of the system, they often introduce ad hoc searches or additional components. However, the original stakeholders (those who approved the product and had a clear vision of its intended function) often lose sight of how the tool has evolved over time. Miscommunication or a gradual shift in priorities can lead to the tool drifting out of alignment with its initial purpose. Business owners and data owners, who typically engage with the tool only at a summary level, may not be fully aware of how significantly its use has changed.

This is why it is crucial to involve data owners and business analysts alongside the technical teams who manage the system. Aligning these perspectives ensures that business requirements are met while also addressing any reasons for deviations from the original scope.

Security Posture

Many customers use Splunk as a SIEM, and ensuring its proper use as part of an overall security posture is closely aligned to the business objectives. Frequently, new ad hoc searches, additional use cases or extra data elements arise which may not contribute to the overall security requirement. The opposite may also be true, with use cases missing against key requirements or risks which have emerged over time. Migrating to cloud is a good time to review the overall security requirement of the platform, ensuring that the business risk register and threat modelling is up to date and the use cases in the platform are the correct ones. It is also a good time to review framework compliance, either from a regulatory or best practice perspective, to ensure that the platform content is up to date against the latest best practice. This exercise can also help identify any gaps in the security posture and ensure that the correct size environment is provisioned against the organisations threat detection requirements. This approach can help optimise system processing demands but also ensures that only the necessary data is ingested, making the environment more manageable and efficient in the long term.

Regularly reviewing SIEM content against an organisations risk and threat is something which should be periodically carried out, but migrating to cloud also provides an opportunity to complete this exercise and ensure the new Cloud platform will serve the organisations needs over the coming years. For customers who are yet to embark on a detailed risk or threat review, this is an ideal time to build a structured framework and guideline for ongoing security assessments.

Operational Model

Ensuring that a monitoring platform continues to meet its business requirements needs a robust operating model. As mentioned ad-hoc searches, apps, use cases and data sources can be introduced to the platform over time. Oftentimes, this can happen in an uncontrolled manner, and it is unclear what components are driving real value into the product and what are contributing to uncontrolled usage of the platform. Many customers find the transition to cloud to be an ideal time to review the operating model and control policies of the platform. An operating model can cover multiple areas including the overall business requirements, the financial and people resources required to operate the platform, the roles and skills required in that team, the operating processes and governance and any supporting technology requirements.  Governance, as an example, is a key aspect including defining an RBAC strategy for the platform and key roles and responsibilities of administrators and users is key. Ensuring auditability of the platform to know what has been changed and when is also critical in controlling the use of the platform, as another example. Overall, an operating model that worked for an on premise deployment, will be different to that required for a cloud deployment and this should be considered as part of the migration strategy.

Product Architecture

When migrating to cloud the product architecture and technical elements of the build, should of course also be considered! Building on the business objectives and having a clear understanding of overall requirements allows for a more streamlined infrastructure, ensuring that only the necessary servers are utilised. Even in a cloud-based model there is often still a need for hybrid or on-premise servers to handle certain data transmissions. By identifying exactly what is required in a hybrid or on-premise environment, businesses can reduce hardware costs and minimise the time and resources spent maintaining unnecessary servers; particularly those that are underutilised or redundant.

Data Catalogue

Many of these considerations: business objectives, security posture, architecture and operational models are interconnected. Underpinning all of this is the data. For operational monitoring, understanding the data in an organisation and which is relevant to the monitoring, is of key importance. When an organisation moves to the cloud, it presents a good opportunity to review or create a well-structured data catalogue.

A common challenge for customers is the misconception that more data automatically translates to greater value. In reality, more data often means increased volume, higher costs and greater management overhead. Often, the goal should be to ensure that only essential data is ingested and utilised. Having a clear data catalogue is a key step in understanding what data you have and subsequently identifying what needs to be in the platform to meet the business objectives.

Conclusion

When faced with the challenge of migrating from on premise to cloud, there is danger of thinking that the challenge is just a technical one. In this blog, we hope to have highlighted that there are several other aspects that should be taken into account. Moving to cloud is a good time to reexamine exactly what the business requires from its monitoring, what it requires from the platform and how that platform will be operated. Taking these, and other areas into account can help ensure that when the platform is on cloud, it will deliver value to the business well into the future.