Phase 4: Preparing for Splunk Cloud Platform migration

Firewalls for data forwarding: Confirm there are NO firewall rules where you can’t forward your data. 

Reconfigure firewalls & resolve any issues where you can’t send all your data to Splunk Cloud Platform.

Firewalls for on-prem integrations: Confirm there are NO firewall rules where you can’t integrate on-prem services with Splunk Cloud Platform:

• Including Adaptive Response Relay on a Heavy Forwarder for Enterprise Security, Enterprise Security & Phantom, and User Behavior Analytics.

• Phantom can receive events from Splunk Cloud Platform directly if customer opens firewall rules.

• Could be a blocker if Splunk SOAR or Splunk User Behavior Analytics sit in a DMZ and have no internet access.

• Could be a blocker if you have to wait for the HF to be provisioned, configured and implemented mid-migration.

Adaptive Response Relay HF: 

• Will need to connect to the Splunk Cloud Platform Search Head(s) AND Phantom.

  • Confirm connectivity - supply IP of Cloud ES SH if required to be added to F/W.

• ARR only tested up to a couple of hundred alerts/notables per day. If there are more Phantom will need to connect directly to the Cloud ES SH(s).

Splunk SOAR:

• Forwards via HTTP Event Collector - confirm Phantom can send to internet.

  • If unable to, implement a HF as Intermediate Forwarder, with HEC inputs, and the customer Splunk Cloud forwarder app.

• Can search ES Cloud SH - submit JIRA requesting IP of Cloud ES SH, so you can add to your firewall rules.

• Enabling the Splunk API port (8089) is now a self-service option. Please see this link for details.

Splunk User Behavior Analytics:

• The host will require internet connectivity, to search the Splunk Cloud search head(s).

• Additional SVCs for data sources searched - Please progress with the Account Manager the sizing requirements for UBA searching Splunk Cloud.

Forwarding certificates: Confirm there are no on-premises forwarder certificates not supported in Splunk Cloud Platform. 

• The use of requireClientCert = true in server.conf is not supported in Splunk Cloud Platform.

This is an edge case for when you had the setting enabled, but its not supported in cloud.

The cloud forwarder app contains all the necessary configuration to securely forward to your Splunk Cloud Platform stack, along with the ability to whitelist 100 IP ranges of forwarders.

However, if it does not contain the ‘requireClientCert = true’ in server.conf, it is not supported in Splunk Cloud Platform. 

Extended change windows: A blocker if you need to upgrade your on-prem environment in order to migrate your data to cloud. GCP needs version 8.1 at minimum. 

If you have a n-month change window, ensure that the migration doesn’t start too soon and/or the migration activities dependent on the upgrade are aligned to your next feasible change cycle. 

Plan for non compatible apps: Make a list of the full catalog of apps that are not compatible with Splunk Cloud Platform.

For any apps that have to be upgraded to a compatible version before migration: 

• Ensure proper tasks & timing for this upgrade is incorporated into the migration plan.

If a third party app requires data pull from Splunk over some unsecure port, Splunk Cloud Platform will not allow this and may become a blocker during the migration if the app is mission critical for you. 

• Consider workarounds for how you can accomplish the same tasks of that app.

• You may be able to set up a heavy forwarder but this may delay the overall timeline by 2+ weeks.

Forwarder versions: Ensure all forwarder versions are supported as per the Splunk Cloud Service Details. You cannot send data into Splunk Cloud Platform if you aren’t on the latest versions. This is a blocker for the final step of the cutover. 

You can start the migration, but you need to ensure this is happening in parallel and forwarders are fully upgraded before you get to the step of forwarding data. 

Splunk PS can help with the upgrades of these configurations through the migration engagement. 

In some cases, it may take you months to upgrade your forwarders. In this case, IFs could be implemented as a short term fix. 

Proper infrastructure and resourcing: Make sure you understand the resources needed for the migration to be successful and delivered on time (people, hardware, etc.). 

Assess any hardware or resources required for the migration.

• Infrastructure example: a customer required additional hardware to copy their on-prem data to the cloud. Their existing environment and infrastructure could not handle the workload required to fork data to on-prem and cloud.
• Resource issue example: A customer required additional hardware, They didn’t have people on site to receive the hardware and set it up, causing a long delay in our timeline. 

Compliance requirements: You may have compliance related considerations that may result in unique migration requirements.

Validate that there are no compliance requirements to consider for the migration. Consider the potential impact to the solution and timing of the migration.