BookmarkSubscribeRSS Feed
JohnJPS
Quartz | Level 8

This question pertains to a migration from SAS version 9.4M4 to 9.4M6.  We are planning a SAS migration to a different data center.  We would like to build up the new server stack and then cut over gradually.  Unfortunately we have a lot of metadata, and we're finding that when using the SAS Migration Tool (SMU), it only comes into play at install time on the target servers.  So if we install in advance of the cutover, the metadata of the new environment gradually grows stale as users continue to live in the old environment prior to cutover.

 

This suggests that we not build in advance: that we pick a weekend and migrate by shutting everything down in the source environment, running SMU there to collect everything, then build the target environment using SMU, and bringing everything back up on the target. We find that when trialing this process, it's challenging to fit in the space of a single weekend, given multiple servers involved and validation/testing steps to follow installation.

 

I was wondering how other have worked around this problem, or if the only resolution is to extend the weekend work window for "migration weekend"?  Insights appreciated.

6 REPLIES 6
AnandVyas
Ammonite | Level 13

Hi @JohnJPS 

 

Usually in this scenario, you can use combination of SMU and the promotion tools that SAS offers.

Promotion tools offers flexbility to move selected content when required.

 

https://documentation.sas.com/?docsetId=bisag&docsetTarget=p04l8c3fo8tpyhn103dps7pxvru2.htm&docsetVe...

 

Thanks!

JohnJPS
Quartz | Level 8
Thanks Anand. That seemed reasonable to me on the surface - good to see a vote of confidence in it.
JohnJPS
Quartz | Level 8
replying to myself... we are also considering the idea of a "metadata freeze" where we ask users to find other work for a few days, and extend our "migration weekend" to give more breathing room. I wonder if it's possible to forcibly make all metadata read-only? (e.g. run SMU on the source, then force everything to read-only, but leave the system up and running, e.g. so batch jobs can run, MAS is alive, etc).
Technolero
Pyrite | Level 9

I found myself in the same situation in the past. We had a LOT of metadata and multi-machine deployments. What I did was make shutting everything down and running the SMU the first step in the process, that way you have up-to-the-minute metadata captured. It definitely added a lot of time to the small upgrade window, however it was successful each time I performed the upgrade in this manner.

JohnJPS
Quartz | Level 8
Thanks @Technolero. Do you also have SAS Contextual Analysis and/or Decision Manager (Decision BuIlder / Micro-Analytic Services)? Did artifacts for all of those migrate correctly with the SMU?
Technolero
Pyrite | Level 9

@JohnJPS: My environments were all straight EBI without any solutions. After using the SMU successfully on development and test environments, however, I was comfortable with the process and the production upgrade was straightforward as well.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 6 replies
  • 2088 views
  • 3 likes
  • 3 in conversation