I’m going to go ahead and call it – we are now on Managed Hosting.

I can tell because when faculty contact me they have started referring to “the old Blackboard system” as our still-functioning self-hosted environment, while the MH-hosted environment is simply “the Blackboard system.” Although my old system will still be up until June 15, 2014, the primary focus of faculty is now on the Summer and Fall course sites, all living on the new system. The only reasons for anybody to go to the old system are to grab out course Export files, or check on Spring 2014 grades… and even the grade issue is nearly over, as final grades ought to all be submitted at this point.

I will say that I keep running across unexpected difficulties with the MH system. For example, file uploads (whether using the Import Package tool or simply attaching a file to an Item) take what seems like a horrid amount of time complete the upload process. Apparently while on the local-hosted system we were all spoiled for upload speeds. Also, I never did get our local-hosted system up to SP14, which I am now very glad of. I’ve already got an upgrade to the “April release” version scheduled in mid-August, and I will be delighted to leave SP14 in the dust.

Palomar followed an atypical path to get to Manged Hosting; no migration of old courses and users, no attempts to continue supporting legacy data integration methods, no attempt to retain the old DNS listing; but each of these has ultimately worked out as a positive in the long run. In a couple weeks I get to finally shut off our local-hosted system, and within a year I expect that most faculty won’t even recall there was an old system.

Turns out that most of the building block configuration worries were actually non-issues. Because we aren’t truly “migrating” our content from the local system to the MH one, we can get away with configuring all the B2s as wholly new environments, and the publishers and other vendors may need to make some changes after our live courses have launched. This is truly good, and makes me feel that much better about the decision to start with new semester content only on the new system.

It also amuses me how often the Bb techs have tried to blame something on “the content you migrated”; we get to respond along the lines of “oh, you mean the total lack of content we migrated, yeah that could be a real source of trouble.” It sure would be nice if more techs would ask for details BEFORE trying to lay blame on events that may never have actually occurred.

The Summer 2014 courses are already ready on our MH system, and instructors are going in and prepping course content. There’ve been a few bizarre issues that have cropped up (like when one evening we lost the ability to add or edit Items, or see content areas containing content) but working with the MH tech team is a fairly easy experience. Of course the real test will be when students start accessing the courses, and even that we’ve lucked into a sort of “soft launch” with; there are a few intersession courses starting May 20, then the six and eight week courses starting June 23. Of course the true load on the system won’t hit until August, when Fall kicks off, but by then we’ll have several months of live use.

The internal confusion factor is high for me right now, though. When someone asks for Blackboard assistance, I’ll sometimes have to pause for up to a minute before knowing which of our systems to go to. (We’ve got local production, MH production, local sandbox, and MH test systems; it just gets excessive, ya’ know?)

Perhaps it’s true that “the road goes ever on, and on” but this particular branch of the road, to Managed Hosting, is almost at an end. Hooray!

I’ve had access to my new Managed Hosting Blackboard environment for almost two weeks now; it’s a bit amazing how many niggling details needed to be dealt with, before the system is ready to unleash.

Among these issues:

• Decide on the internal appearance of the system, consistent with the college brand. (Let me tell you, silver and red aren’t as easy to work with as some might expect.)
• Install the extensive components (building blocks) on the old system.
• Configure these building blocks; this is extra tricky as many blocks actually connect to external data stores, such as publisher tools.
• Set up the listing of… everything. Modules, tool listings, default course menu entries, user privileges… if I get these right BEFORE launch, things will go far better than retroactive changes.
• Establish data integration frameworks; to my surprise this ended up being nearly the most straightforward piece of the puzzle.

Not everything is done already (for example, I’m still waiting to hear back about some of the building block issues relating to switching systems), but by and large the environment is ready for launch. Of course THAT process will require some finesse all of its own.

More on the launch process later. So far, so good.