The Plan: Step 4 — Other Options…

Finally, finishing out this string of posts with my thoughts on the last few categories of migration options:

“3rd Party Tool replacement.”

I’m not talking about Casahl or nintex or even InfoPath here. I’m referring to specific apps written by a software vendor to solve a specific business problem. Unless you are a small business, odds are that someone has written tools for the processes and problems specific to your industry. It is worth doing research to find out what those tools are.

When deciding whether or not it makes sense to build vs. buy, often your organization has already developed a strategy on that decision. But if there is leeway in the decision process, it will come down to cost and maintenance.

What is the cost of the software vs. the cost of development? Can development be done by employees, or do you need to spend money on contractors? Once the tool is written, what is the cost of maintenance? And how does that compare to any maintenance costs charged by the vendor?

Think carefully about the level of support the vendor can provide. I know when you Google domino and sharepoint, one of the vendors that is near the top of the list has terrible support. So bad that they have lost multiple customers purely because of their poor service. Last I heard, they said they recognized the problem and would solve it, but it was too late for me. So I recommend testing their support before you buy. I tend to send a fairly complex request for info that would require a technical answer before I buy any product. If their sales dept cannot get me a reasonable answer quickly, I steer away from that vendor.

But when you do find a vendor that provides good support, has a good product, and can sell it to you for less than the cost of redeveloping an application, then this becomes a very good choice.

“Decommission”

Most Notes environments have been around a long time, and have a bunch of old discussions, document libraries, teamrooms, etc just lying around. There is no need to migrate old applications. However, it would be unwise to just delete them either. Find out who did own the apps while they were still used. Find out if they would like to keep the data, as well as how and where. At a minimum, a platform-independent backup would be wise. Don’t just back up the .NSF. If they want the data back after Notes is gone, you’re busted. Instead, export. Plain text, excel, PDF, ODF, whatever. Pick a document format and export it. Give a copy to the department that owned the data.

But also look carefully at the business processes supported by your Notes apps. In one migration effort in my past, we say down with the business and questioned every single process to see if it was what the business really wanted. They realized that their processes were far out of step with their industry’s best practice, and ended up reworking their entire business, which also made it easy to decommission the apps that supported the outdated processes.

I highly doubt most migrations will go to that level of analysis on their business. But a nice middle ground, questioning if the business itself can be improve as part of the migration will often allow you to clean up some older apps.

“No Action Required.”

This category exists for the apps that just don’t need anything as you migrate off of Notes. The logs, the catalog, the NAB, templates, admin databases, etc. They exist purely to support the Notes system, and can pretty much be ignored until the servers get shut down.

One caveat, though — make sure that over the years, you didn’t add any data or process into these apps. I’m thinking mostly of the NAB. It often gets used for more than just basic directory and authentication. Determine if you need to find a replacement data store for information in the NAB.