Migration considerations

Migration considerations

This topic discusses various issues and considerations you should review before upgrading to Splunk 3.3.

You should also review the Known Issues for additional information before you upgrade.

Stop Splunk and back up all of your files

Before you perform the upgrade, stop Splunk and back up all of your files, including configurations, data and binaries. Splunk does not provide a means of downgrading to previous versions; if you need to revert to an older Splunk release, just reinstall it.

Users of LDAP on MacOSX Leopard should back up ldap.conf before upgrading via DMG to 3.4

If you are using LDAP authentication and are upgrading from any version of Splunk to version 3.4, the Leopard DMG manager will delete your existing ldap.conf and replace it with the newer ldap.conf.default. If you've made changes to ldap.conf, make a backup copy of this file before upgrading to 3.4 and then reinstate it after you have upgraded.

Bundles configuration directory structure changed and renamed

Starting with version 3.3, Splunk's custom bundle directory structure and terminology have both changed. Bundles are now referred to as applications, and a new directory structure is in place. The existing directory structure and nomenclature will be supported in 3.3, but a switch to the new structure will be enforced in a future release. For detailed information about the new applications directory structure, refer to the documentation about configuration files.

Splunk provides a script for migrating your existing bundles directories to the new structure. Refer to these instructions for more information

Scripts in /splunk/bin may not be saved

• If you have configured an alert to call a script, that script resides in $SPLUNK_HOME/bin/scripts. Make a backup of these scripts and reinstate them after the upgrade.
• If you are using a Splunk-provided archiving script (compressedExport.sh or flatfileExport.sh), these scripts may be removed or overwritten upon upgrade. Make a backup of these scripts and reinstate them after the upgrade.

Saved searches and search operators

Be aware of the following regarding saved searches:

• If the search contains fixed scheduling, and actually takes longer to run than the interval allows, the search will not work.
• If your search contains foo=bar and you have an indexed field configured from previous versions as foo::bar, your search will fail if bar isn't anywhere in the raw data of an event. Make saved searches that fail for this reason work by either:
  • adding or changing INDEXED = True or INDEXED_VALUE = False in the stanza for foo in fields.conf.
  • changing your search in the search bar by replacing foo=bar with foo::bar.
• Metadata commands like | admin or | metaevents are not supported, and will generate a warning.
• Some field names for Windows-specific deployments have been changed. Splunk provides a script for migrating your saved searches, refer to these instructions for more information.

Saved searches and prefs.conf references to "query" in context of the "admin" command no longer supported

If you have a saved search containing the admin command which also contains a reference to the query field, you must recreate your search so that it does not use query. The admin command now uses search instead of query.

Affected search examples:

| admin mysavedsearches | rename query AS term stanza as name
| admin mysavedsearches | top query

Unaffected search examples:

| admin mysavedsearches | rename stanza as name
| admin mysavedsearches | stats count(name)

Changes to indexes.conf

If you have made changes to the default values in indexes.conf, the configuration will not migrate. Make a backup of your changes and re-add them post-upgrade.

Must upgrade all instances of Splunk in a distributed environment

As mentioned in the Known Issues, you must upgrade all members of your distributed cluster to the same version.

Instances of Splunk deployment server must match clients

As mentioned in the Known Issues, if you are running Splunk's deployment server, you must upgrade the deployment server and all its clients to the same version. Splunk recommends that you upgrade your Splunk deployment server first, before you migrate your other Splunk instances.

If you are unable to migrate all clients at one time, you can set up two deployment servers, one for your new 3.3.x clients, and one for your 3.1.x clients. This way, you can move each client over to communicate with the 3.3.x deployment server as you are able to upgrade it.

• Was this topic useful?
• Post a comment