Self Hosted to RAMP

Hi Heath!

Not *exactly* what you're asking for, but I worked at self-hosted organizations from the very beginning.  Then there was the "accidental sabbatical" that was the pandemic.  After, I found myself at a RAMP organization for the first time.  It took me a loooong time to get used to the level of control I (didn't) have anymore, especially in sql.  In the beginning I was always running up against permission issues, "who is responsible for what", why don't I have report templates, etc, etc.  Once those things got ironed out/I got used to them, RAMP has been great.  

If I had the opportunity to be in on a conversion to RAMP, I would ask at every opportunity "who does this- me or you?" and take the time to explore the boundaries of your permissions.  

We are running the gauntlet ourselves, scheduled to migrate at the end of March. I'm embarking on a large scale clean-up project with our consultant, I'll post the documentation as we develop it in this thread.

We are also in the process of moving to Hosted Services...if anyone wants to join a mini support group, shoot me an email! I would love to compare notes on testing and training 

jlevy@sfopera.com

From the other side of this; we have been on RAMP/Hosted Services/THS since 2010.  If anyone has any questions from that aspect; "how has this worked for people on RAMP?", as Heath Wilder knows, I am always up to answer some questions.  Feel free to shoot any such questions or thoughts to me.  But we went live in 2010 on THS as a brand new organization, so I am not helpful from the side of moving to ramp from something else.

jmoskal@thecenterpresents.org

John A. Moskal II

We did this long, long ago, long enough ago that the specifics, if I remembered them, would be very different anyway (for instance, it was still actually called RAMP).

I'll second Kathleen: the biggest difference for me was the change in permissions structure.  I actually got to ease into that, since RAMP was initially more open with local admin accounts, then tightened up a bit, and then with the move to AWS and the rebrand to THS things tightened up a bit more.  Some specifics: file access is generally less (and of course more awkward) although they'll generally post most folders you request into FileMover.  API server configuration, which I think still has some functional items built in (like ticket reservation limits and maybe seatserver timeout) will have to go through support.  Two big changes that I still haven't fully resolved are the fact that scripts/procedures you build will not have the file access and you will not have 100% control over SQL Server Agent Jobs.  Some things are negotiable, like being able to build and edit your own SQL Server Agent Jobs, others are not.

I'd also like to do some expectation setting.  When we were locally hosted, we had magnificent uptimes: generally speaking they lasted unbroken between upgrades.  At the time of the change I pointed out to everyone who would listen that we had replaced two points of failure (the server and the router in our building) with about 35 points of failure (every hop between Berkeley and Dallas).  This turned out to be painfully true as for years we wrestled with a handful of servers in LA that were just misconfigured enough to saddle us with unpleasant latency but not enough for us to find a way to route around them.  That particular headache is gone and many of those points of failure eliminated with the move to AWS, but there are still many networking but also software and server layers that can, and routinely do, cause issues.  Issues are usually resolved within a few hours, but it is something that will just happen.  What I remind our staff about is that when we did have downtime before it usually wasn't resolvable in a couple of hours because, for instance, the server room had filled up with water.

Good info to have.  I learnt the limited amount I know about DBAing being in a RAMP/THS environment for 6 years before comming back over here to self-hosted.  For my current DBA (who actually has career training, outrageous I know) moving from self to THS will be another shock.  eg: I always had decent access to SSAgent, but not DBmail - which makes sense. The Support environment is small enough down here that we are pretty close and a lot of us have worked both sides. 

It might be 14th Feb talking but - I love you guys!

I've gathered all the customisations, local procs and tables and I'm trying to build a Project Timeline.  

I've done similarly to Jim Reynolds in embarking on a hygiene project before hand and looking to create a bit of structure to some of the processes that we take for granted.  At the core really is a whole data strategy that this sits as a roadmap item but I may be getting a bit grandiose. Lets say the bigger picture a journey rather athan a destination.

We have a lot of legacy and auxiliary data in local tables and views.  Trying to cut through what is necessary and what is shoring up broken busines practice that needs a review is a mission.  As is hearding all of the pieces whilst doing BAU.  I figure I'm going to have a lot of late night timetabling for a bit.

Made the switch some time ago now.  Just like others, the loss of access to things that we were used to have access to was a bit of a pain at first. Just takes time to get full understanding of who can and does what.  

The other main difference/pain point was from the user side. Citrix is not a speedy app. Tess used to open in under 5 seconds when self-hosted, now... well, there is a pause. Can't give time on pauses, as it is different each time.  The other major thing that my users had to get over, is when saving from Tess. In Citrix, the "My Computer" is not the users computer, but rather the Citrix instance. This took time, and with new users, is still an ongoing struggle for them to grasp.  Ended up mapping drives for the users that tend to save often to help simplify this. 

Having to setup users twice is kind of a Pain. Have to set up in THS/RAMP, and then also in Tess Security. Passwords seemed to not sync well between the 2. We moved to Single Sign on and that has helped, sort of. Had/have to train users to use Full domain user to get access with web apps, (TessOnGo).  

Since move to AWS, big pain point is that users are not prompted about password expiring. The clue now that password is expired, is when login, just get blank screen, no icons to launch Live or Test.  Hooping this gets resolved soon.

Once you get past the “I used to do it this way” and embrace the change, it is totally worth it.

Congrats, Heath et al on your upcoming moves to Hosted Services! 

We made the move to RAMP in 2017. Prior to that we had been self-hosted for 10+ years.

Everyone has already made some great points, and I would echo the sentiment of managing expectations and communication. For example, how hands-on does your DBA want to be in the Tessitura SQL server after the move? As my consortium's DBA it's important for me to know when TN staff apply changes to the system or when the backend jobs that I don't have access to (e.g. Analytics loads) are running, so we definitely have discussed that, and continue to discuss that, with TN.

One of the main things I have asked for since moving to RAMP/Hosted Services was a "handbook", i.e. official documentation on all things Hosted Services, to help with those expectations and communication. Happily there's a (new this year, I think) section in the TN Help system just for Hosting, which is a great start!

Moving to Hosted Services was a great choice for our consortium. There are, of course, trade-offs, but the benefits far outweigh any of those. As the person who by default was responsible for all things tech, the move to Hosted Services let me focus on implementing projects for the consortium, i.e. the job I was hired for, rather than maintaining servers.

Bonne chance!

Thank you.  When I was in the THS environment it gave me a lot of time to do more data governance, reports and analysis, and cleaning up workflows across teams. Lots of benefits and still elbows deep in SQL