Paul posted a blog today “Farewell to the SAS 9.2 Replication Wizard” which outlined the fact SAS have announced that the replication capbility in SAS 9.2 is no longer supported. (Usage Note 40834: The Replication Wizard in SAS® 9.2 has been deprecated)
Paul mentions it was probably lack of use that caused SAS to stop developing and supporting the replication capability, but im guessing that it was actually the fact that people used it and it didn’t work that caused the action.
Although replication was a pain to set-up, it seemed to be useful as part of the SAS 9.2 migration strategy, or alternatively intiating a new SAS environment.
What it was mean’t to allow you to do, was fully replicate an environment (say Development) to another Environment (say UAT or Prod) and automatically change all the pointers through the SAS environment to the new instance. So for example automatically changing the name of the servers if you were moving environments across physical or virtual machines or changing userid’s, file paths, ports etc.
So for 9.2 migrations it made sense to create a blank Dev 9.2 environment, migrate the 9.1 production objects to it, test the Dev environment, then replicate the Dev environment upto UAT and Prod.
As Paul quite rightly highlights the only other option was partial migration, i.e exporting and importing SAS Packages and this option is not available for all SAS content (Portal pages and Portlets being one of them until BI 4.3 is out). Its also a pain if you had to do it for 3 environments, not to mention the risk of the environments getting out of sync from day one (compared to day 99 
I know of one NZ site that took the replication approach for their migration, but unfortunately found the replication process didn’t change all references during the process, and so the environments got a little confused (to say the least). Nothing worse than Production updating files or objects in Dev it seems.
So maybe this was one of the few sites using replication, and therefore there wasn’t enough of a user base to warrant making it work properly, but it does worry me when functionality gets de-supported like this (just thankful i’m not in the middle of a SAS 9.2 migration project that was relying on this feature and hope your not either!)
Hi Shane,
You raise some good points in your post. I particularly like the fact you mention the potential for cross-linking of environments which can be nasty when it happens, as well as confusing and hard to troubleshoot.
Something I didn’t get around to mentioning in my post was that I was myself a user of replication back with SAS 9.1.3. I was working with a site that had not yet released their production environment and they wanted to regularly push their entire development environment into test and then prod during the development lifecycle. As the administrator responsible and as someone that prefers automatic error-free processes I customized the replication process to avoid manual use of SAS/CONNECT (I was able to use UNC paths) and then automate some of the manual metadata substitutions like logins, server commands, job flow names, batch job commands etc. By automating everything it also gave me more confidence that I had not cross-linked the environments.
The customized replication process worked really well and allowed me to replicate very quickly and very regularly. However, as soon as the production environment was released and actively used, replication then became impossible because changes were coming from 2 different directions at once. The developers were working on the next set of changes in the development environment and the business users were making their own changes (private/shared web reports, portal pages etc) in the production environment. Any further replications of the development environment into the production environment would have wiped out any production changes made by the business users between replications – which would have made for some very unhappy business users
So once production was released the only feasible way of methodically pushing development changes into production was to export packages from the development environment and then import them into the production environment. One of the SAS papers also suggested checking the SAS packages into a version control system (like Subversion – one of my favourites) to keep track of them.
So my view is that for a reliable, repeatable process that can be used with active production users, import/export is probably the only way to go for most environments. Replication might give you a kick start at the very beginning of a new installation but becomes unfeasible very quickly thereafter. Since SAS 9.2 supports more objects, allows batch import/export and portal content support is coming, I don’t see that replication in future would offer enough benefits over import/export.
So that’s why it makes sense, to me at least, for SAS to deprecate the replication wizard – especially if partial promotion is going to provide (full?) coverage of content. I don’t know for sure why SAS are deprecating it so it is pure speculation on my part
BTW I don’t think I would be too bothered by the replication wizard being deprecated if I was in the middle of a SAS 9.2 migration project. It would still continue to be available to me for use – I would just have to think about moving away from it sometime in the future and I would probably have hit its limitations before then anyway.
Cheers
Paul
Paul and Shane,
What about once a period flush development by replicating ( well , not any more) from production into development?