There are three types of people in the Notes & Domino world, and the type of car they drive (or would choose) may tell you something about them.
Group A are the people who are quite happy with Notes and the apps they are continuing to maintain. Nothing wrong with that. It's a bit like me and my 2002 Jeep. It may be 16 years old, but it's bulletproof, mostly I know how to fix it if something goes wrong, and although it might not be the sleekest, most beautiful car on the road, it serves its purpose well. I see no reason to upgrade to the latest and greatest model.
Then there's Group B. These are the folks who are thrilled that IBM and HCL seem to be finally investing in moving the platform forward. They are eagerly looking forward to Notes 10 and 11, meanwhile they're learning Javascript and Node.JS. To continue the slightly questionable car analogy, these are the people who bought the new Mini when it came out, or the updated VW Bug - they are fiercely loyal to the brand, slightly nostalgic for the good old days, but actually want the product to work and perform under the hood as well as the modern day equivalent.
Finally, there's Group C. Ahh, Group C: the EV crowd... Teslas, Nissan Leafs, BMW i3s and i8s. These are the people who want to completely ditch the technology they've relied on for years and leapfrog into something new. It's also where the car analogy breaks down completely so we won't continue with that. But it's Group C that this article is targeted to: those people who have decided that they want to (or been told that they must) move off of the Notes/Domino platform completely.
Earlier this year, we launched a new product, Teamstudio Export. The idea of Export was to provide an easy way to create simple XML archives of Notes databases. We chose XML as the data format to make it easy (or at least possible) to reimport the data into any other database format, with full fidelity of rich text, attachments, etc. Export was a natural follow up to Teamstudio Adviser, which we launched a couple of years previously.
Click image to enlarge
To us, that was sort of the natural order of things: start by mapping out your applications, analyze and weight them for usage, complexity and business value, and then use that analysis to determine a forward path for each app: retain, archive, migrate, etc.
Since we launched Export, we've had way more interest in Adviser. That wasn't what we expected. But it illustrates the fact that, for the Group C people, they know they want to move off the platform, and so are focused on the mechanics of exporting the data. How are we going to store the data? What format should it be stored in? What are the costs of exporting and storage?
But in fact, none of those questions are even relevant until you've got a really clear idea of your application landscape: what applications do we have? How are they being used? How complex and specialized are the apps? What are the probable costs of migrating? How valuable are these apps? Once those questions are answered, you might find that you have a lot less work to do when it comes to actually exporting, migrating or archiving your data.
So back to the title of this article: where should you start with a Notes migration project? Well, if this is something you're tackling now or in the near future, here are a few basic steps that might help your thinking:
- Catalog
- Start by building a comprehensive catalog of all your Notes databases. You may be surprised to find you have more applications than you thought: many of our customers do.
- Usage Analysis
- Just as you may be surprised to find how many databases you actually have, you may be equally surprised to find how many of them are not being used at all. Or conversely, how many of them *are* being used. Either way, you can get a good sense of some early targets for archiving based on usage statistics.
- Complexity Analysis
- Some analysis of the level of complexity of the application design can give you a rough estimate of the level of investment that would be needed to port the application to a different environment. We've done tons and tons of research and analysis in this area (email me if you'd like to know more) and, trust me, you can go crazy with this stuff, but when all is said and done, the more code there is, the more complex the application is. But it doesn't hurt to apply some basic analysis to your applications to build a complexity score for each app.
- Business Value
- This is an important part of the mix, and perhaps unsurprisingly, there is no way to divine this automatically by scanning the application in some way. This data point has to come from a human.
- Triage
- Once you have gathered the key pieces of data above, it's time to combine them together to start to group your applications into buckets. For example, an application with low-to-zero usage, low complexity and low business value is probably a candidate for simple archival. If an application has high usage and high business value but low complexity, then it's a candidate for porting to the new platform of choice. If an application has low usage, high complexity and high business value, then there may be a case for leaving well alone and leaving the app on Notes for the small number of users.
Of course, all of this could be achieved without the benefit of any tooling. But as with many of these tasks, it would be pretty labor intensive and error prone. That's why we built Teamstudio Adviser, which can simplify these actions down to a few clicks. I think it's the obvious way to solve this problem, but then I'm biased.
If you're a fully paid up member of Group C and thinking about some of these issues, contact us to chat. We'd love to talk to you about this, or any aspect of your Notes data migration project.
(Postscript: OK, so I drive the Jeep but I would choose the Tesla if I could. But like I said, the analogy was pretty tenuous in any case!)