I'm currently working on migration of a single-node installation to indexer and search head clusters.
Specifically on migrating the scheduled searches and alerts to the SHC, the recommended way of doing this appears to be to use the Deployer to deploy an app containing the configuration to the members. I've tested it - it works - and if I do the initial deployment with the savedsearches.conf in the 'local' directory then it allows the SHC members to make updates via the UI using the standard sync mechanism, and those changes won't get overwritten by future deployments because they are in the 'local' directory.
So far so good.
But, I am curious - is there anything wrong architecturally with stopping all of the SHC members, replacing the SPLUNK_HOME/etc/apps/search/local/savedsearches.conf with the same, identical file copied from the single-node install on each member, and then bringing them up?
I'm led to believe this would work, but I'm also not sure if it would cause any consistency issues with future updates and sync across the cluster.
Why would I want to consider doing this? Mainly to avoid having to look for scheduled searches in two places ("search" and "migration" apps) when making updates via the UI, which will be the main way users will add and edit scheduled searches.
Any other potential pitfalls with this approach? Or methods that would avoid having to maintain scheduled searches across two apps?
I'm only asking here about the scheduled searches. Everything else has been migrated to the correct locations via the indexer/search head cluster mechanisms, so for the purpose of this question you can assume that everything else regarding field extractions, indexes, etc. for those scheduled searches has already been migrated and I just need to migrate the scheduled search definitions.
Thanks in advance.
