What to do when QuickPlace (or any product, really) gets to end of support - a treatise
Category QuickPlace Lotus QuickrWith QuickPlace 7 and its awkwardly-dubbed progenitor Team Workplace 6.5.1 on their death beds counting down seven more days, I've been asked by a number of upgrade-shy (or off-maintenance) companies and individuals for advice on how to move ahead. You see, it doesn't matter to users that the product is 3 years past the introduction of Quickr. If you have not upgraded for whatever reason, the users of that mission-critical document repository, team space, extranet, re-branded, personal, public, CEO-likes-it, "thing" are not about to walk away from their documents. In fact, they will continue to demand a service level similar to what they've received for 4 to 11 years.
Here is where I mention - for those of you who haven't loaded that link out of curiosity - that Notes and Domino 6.5, Lotus Enterprise Integrator 6.5, Lotus Learning Management System 1.0, and Lotus Component Designer 1.0 also meet their untimely ends in a week. That last one's a bit of an odd bird, since I don't think it was never officially released for sale. I know, I wrote the certification exam for it while in beta. Go figure.
What I endeavor to do here is lay out the choices you have as a company next Friday and beyond, and in fact any time a product - IBM or otherwise - reaches end of service. Not every choice applies to every company - in fact you may only have one or two based on your situation - but hopefully by delineating them here I can give you a sense of what is involved for each choice, whether it takes investment or not, and some pros and cons. So, here we go.
Do Nothing
A common approach to old software, Do Nothing is popular among IT shops where there is less governance and more freedom to experiment (which may have gotten you into QuickPlace in the first place), where you have no corporate guidelines dictating that you run only supported software and stay current on maintenance contracts. Of course this is and always has been a risk, since you can no longer call the vendor for support. If Do Nothing and its Siamese twin brother We Don't Have Budget For This is your approach, I strongly suggest you follow my five-step program:
1) Secure a copy of the installation media
2) Record all admin passwords for potential reinstallation, recovery or rebuild
3) Document your directory configuration, Domino settings, QuickPlace settings, configuration settings, SMTP, firewall, etc etc
4) Do backups - even using poor man's backup as Joseph Hoetzl explains in his excellent Lotus wiki article (it works in old versions too)
5) Pray, or whatever it is you do to ensure success
I don't actually expect anyone who is using the Do Nothing approach to follow my program, because by its very nature people who Do Nothing take a more low-intensity approach.
Upgrade Already
Whatever the reason, some companies have a culture of rationalizing lack of momentum. Once you get onto a version of software that generally works and causes few calls to the help desk, it's not uncommon to just hang onto it. Look at Internet Explorer 6, a nine-year-old piece of trash browser that is still the "corporate standard" at a number of companies. Unfortunately that standard is a) buggy, b) full of security risks counter-measured by edge devices because of the risk, c) incredibly less functional than modern browsers, and ... oh never mind, sorry I got off on my IE6 rant again, didn't I .. where was I?
Oh, yes, QuickPlace.
Let's assume for a moment that you either have maintenance on your Lotus software or can reinstate it without chopping down a rainforest for the paperwork, shall we? Upgrade Already. Using old outdated software is counterproductive at best and irresponsible at worst. That's right, I said irresponsible. Handcuffing users with old functionality, bugs, web 0.3, and security risks for the sake of - temporarily - keeping call volume down is no way to support a business.
Here's why this happens. IT departments who are generally in charge of all software (a horrible idea, but the subject of another post later on) live with a scarcity mentality. Their budgets are fixed and squeezed tighter all the time. They want software to just work - and if they find a magical combination, they'll stick with it for as long as possible and longer than reasonable. So you IE6/QuickPlace/Notes 6/Windows 2000 shops, I contend that you need a little introspection and a real housecleaning of the dusty old software. Your job is to enable the business with technology, not hinder it with arbitrary technology decisions and "company standards."
If you're not in IT, and you believe these standards are important, you have been brainwashed. IT departments worldwide have created cultures of lemming-like users by enforcing "standards" based on scare tactics ("Oh, that Notes update will break the central database and fried the matrix," or "Our ERP system specs dictate we must stay with IE6 or nobody will get paid."). A secondary tactic is to implement (or outsource) change management procedures so cumbersome that it takes three months to get a new font for your marketing department to use, meanwhile missing the annual report production deadline by - you guessed it - three months.
Sidebar: I once sat in on of these outsourced IT operations in Detroit looking at an invalid XML file in production, and indicated the one line change necessary to remedy the problem. I was told, in no uncertain terms, that in order to remove the duplicate </server settings> line in that file required my write-up and recommendations on a standard form, a review by the operations committee (next Tuesday), a technical review by an expert (next Thursday), a re-review by the operations committee (following Tuesday) and implementation by another technical expert (my hands could not touch keyboards) the following weekend. I bit my tongue, told them that was ridiculous, that their server was misconfigured, that their technical "expert" was the idiot who had screwed it up, and that they would have to take my word for it as the subject matter expert. I made the change when they went into their next committee meeting.
You'll notice that in all of this, I haven't advocated upgrading to the latest version without thorough testing. You have to be cutting edge, in beta programs, testing and playing with features in order to properly keep your company up with the rest of the world. Three years is plenty of time to let the bugs work their way out, and nine is just ridiculous (and irresponsible). And I've also not said that every upgrade is easy. If you have customizations, QuickPlace can be a bit of a pain to upgrade to Quickr 8.2. You may need help. (Cue IT scare tactic, someone somewhere is quoting me: "Novak says QuickPlace is a pain to upgrade," I bet my Mac on it...). One more thing, my financially-savvy reader, have I mentioned that if you're on maintenance and don't upgrade, you've paid about 50% the original price of your software acquisition to go nowhere? Upgrade Already.
If you're not in IT, it's likely that you don't know what you're missing, so I strongly suggest checking with outside sources. Read a blog, check out the vendor website for feature lists and case studies. It's OK, they aren't looking.
Kill It Softly
There are companies where QuickPlace never really took off. You bought licenses, with all good intentions (or the intent to punch up or preserve your budget - how many of you live in the "if we don't spend it we won't get it next year" world?). Some places were created, but you see more drop off than start up all the time. You neglect it, don't install fixpacks or really officially support it. New PCs are purchased that don't work with the ActiveX controls, or you have issues with your old hardware. Maybe you never trained people or even informed them it's there - the Rogue Server Crowd. And, you've found some whiz-bang new way of collaborating in your organization called electronic mail. Your culture adopted it 20 years ago and while the CEO still types everything in lower case, it works for you.
Alternately, you either don't need (dodging poison darts from IBM) or are unable to justify web-based collaboration. Maybe you bought Portal Extend and got QuickPlace as a bonus, like the cool tattoo at the bottom of a box of Cracker Jacks. You installed it and are now using the installation media as a coaster in the break room. To you, the unenlightened, I suggest giving up altogether. It's like pushing a rope and as I don't waste time bending the laws of physics I won't even try. Kill It.
But don't go willy-nilly turning off VMs or servers and repurposing the hard drive for your newfangled Doom 3 network, you need to Kill It Softly. Why? Because there is likely some really important stuff on that server. Stuff that should have been managed, could have been made very useful, and might even remain only there. In fact, the server may contain critical, sensitive information and need to be accessible for years to come. I know of QuickPlace servers where the engineering plans for cars were created and stored, weapons developed, billion-dollar web projects planned, multi-billion dollar mergers discussed, and insurance documents placed for safekeeping.
If you're in IT and considering retirement of QuickPlace (vs. Upgrade Already, Do Nothing, or the others that follow), it is critical that you communicate with ALL users (not just the managers of the places) to ensure that no critical data is left behind or lost. And, you need to ensure that those users have another repository - not their local hard disks - available for any critical information. Note that I say information, this is key. If you've thought of QuickPlace and Quickr as simple document repositories, you're missing that conversations and context behind documents can be as important as the attachments themselves.
One of the great things about web (and Notes, and gMail, etc. etc.) collaboration is that you can visualize context through threads, combine metadata and documents, and complement attachments with rich text and comments. The X-35 prototype attachment saved away in a filing cabinet, or on a hard drive, loses a lot when separated from the thread detailing evolution of its design and the final comment of the nuclear engineer in rich text that says "this thing will never fly" right before plummeting to his death under suspicious circumstances, now, doesn't it?
So if you're in the Kill It camp, make sure you do the right things to make it Softly. Communicate with everyone. Drop places by attrition, managing them on a regular basis during the wind-down. Give users alternatives with proper governance over critical information. Consider using tools, consultants, and programming wizardry to pump the data to somewhere safe. And make sure the death is properly planned and not too fast. If you're in IT, believe me, you do NOT want to the one who made the Kill It Quickly decision and executed it poorly when the CEO can't find her merger documents, midyear reviews or golden parachute PDFs in that Firedog link thing you once helped her set up.
Bottom line, odds are that if you're killing QuickPlace it wasn't properly introduced, and likely wasn't taken care of in the first place. If you're in IT, shame on you, if you're not, and your QuickPlace server is being killed off after years of neglect, what do you think is going to happen to the next collaboration platform your company puts in? The problem is indicative of attitude and culture, which don't change with shiny new software. It'll get old too someday.
Health nuts are going to feel stupid someday, lying in hospitals dying of nothing. - Redd Foxx
Be Extorted
One of the most ridiculous things I've seen happen in companies using old software is that instead of Upgrading Already, Killing It Softly, or Doing Nothing, they actually choose to put themselves in a position where they have a critical need for the software and agree to pay a premium for extended support from the original vendor. I've seen it go on for years and years, sticking with the same version of whatever (let's just say Notes 4 or SmartSuite 9.7 or Office 95 or - dammit - IE6 - dammit, for example), keeping some poor people at the vendor on the line for providing development fixes to ten year old software, and paying out the nose. If you're in the Be Extorted crowd, you may as well start attending Be Ashamed group meetings. I hear they have a twelve-step program.
Who benefits from this idiotic behavior? Not the company. Not the vendor, who could be giving their soul-sucked developers something more interesting to do than contemplate the impact of HTML emails on Notes 4 rendering or figure out why Approach won't work with MySQL on Windows 7. Not the customers of the customer, who get email or documents poorly formatted. Not the users who are in the dark ages, growing more and more hateful of the software because it must be the software's fault for being so out of date and hard to use. Not even the sales rep, who might get a pittance on the maintenance extension but would much rather sell modern software than extended warranties. Not product management, to whom said customer is useless for market research and product feature testing. Not business partners, who are so busy ramping up modern skills to compete that they grow disdainful of the dark age customer who pays a vendor for a trouble ticket system instead of planning for the future. Trust me, it's a lose-lose-lose-lose-lose-lose-lose-lose.
Oh wait, there's ONE department that benefits. Human resources! They can very easily replace what was once a vibrant, expert-level, high-skills IT workforce with a bank of phones and low-wage helpdesk people. Finally! H.R. can justify its existence to line management through cost reduction wins. In the long run, not so much, since this entire concept is predicated on a culture of apathy. If that is perpetuated, it won't be limited to software. I personally don't want to buy a car, shoes, electricity, or food from a company that neglects its IT infrastructure so long it has to resort to extended support to maintain minimal capabilities in the software afterlife.
But if you're big enough, and you ask, and you pay, you can probably buy your way into another year. Maybe two. Have fun with that.
Business Partners
In the end-of-service situation, lacking internal skills to upgrade, a very reasonable alternative is to contract with a vendor-certified (or at least industry-proven) Business Partner expert who has been around and known, fixed, worked with and built for the dead software version since before its inception. There are plenty of small shops out there perfectly capable of helping, troubleshooting, planning real upgrades, executing, migrating, exporting data, and more because unlike your organization that is stuck on five-year-old software, they have worked with numerous implementations and all versions.
They know the tricks of the trade.
They have the switches and tools.
They are the A-Team.
Many know more about the old version of the software than anyone left at the vendor knows, because they all moved on to new versions or other platforms or other hot new Star Trek assignments years ago. These partners are invaluable, available, and can do the heavy lifting while advising you on a path forward that doesn't involve death, brainwashing, apathy, or zombies (I threw that in because I always wanted to write about zombies on my blog, but never had the opportunity. If you're still reading, thank you for your attention.)
Business Partners can help you cross the dangerous end-of-support to upgrade bridge because they've already performed numerous such operations. They can advise you because they've seen it all, from that one line of XML to the undocumented repair switch to the multi-database search corruption issue (now I'm making things up, but you get the idea). They know more than you do, and might know more than the vendor, about the idiosyncrasies. And most if not all of them are small businesses and happy to work with you, even if it means airing dirty laundry. Feed them and treat them well and they will be loyal and helpful expert-level adjuncts to your organization and help guide you from your current untenable situation to a more enlightened and productive state. Just don't give them too many rules, policies, procedures, or roadblocks, or they'll end up in the same situation as you - just without the obligation to show up.
Bottom line, Business Partners are available to support old versions of software after IBM or the vendor in question has washed their hands of it and moved on. Those partners, like you, cannot open a PMR or trouble ticket, but do present your most likely solution to any problem that might come up. Some are are more willing to let it drag on than others, so be sure you are clear about the length of support you want and plans to upgrade or kill up front. There are partners on all continents save Antarctica, possibly my next home office, so ask your IBM reps, do some searches, remember this stuff is not necessarily regional, and get some help.
Conclusion
There you have it, fair readers, my opinion on old software in one long combination of thought, rant, and sesquipedalian blather. If I've scolded you, I'm sorry (I'm not), and if you need help and guidance, you now have something to think about. Feel free to email me with your own situation and I will happily give you advice on your unique situation. rnovak at snapps dot com.
@Copyright 2010 Rob Novak, All Rights Reserved.
Category 
Category 
Category 