The Plan: Part 1 – Create an inventory of existing Notes apps

Many of you may be saying — don’t we already have an inventory via the Catalog?

Partially. Notes Apps do not have to be in the catalog, for starters. But the real problem is that the catalog is not laid out in the way I would recommend. This can be resolved via design changes, but let’s step back before we get into that.

As one carries out this plan, the inventory acts as a checklist of action items, and becomes the tracking DB for your migration:
Look back to the previous post for a second. Each step is an action item that needs to be taken on each database. Your inventory is your tracking system for this process. It will allow you to carry out the plan in parallel on different databases, rather than sequentially on your entire environment. This in turn lets you work on the “low-hanging fruit”, and not let your problematic applications (and you will have some) hold up the entire migration. This parallel approach won’t give you an overall timeline or cost for the migration, but I have yet to see a migration that plans to that level before attacking the easy stuff.

Whether you use the catalog or make a new DB for your inventory is up to you. I prefer a new DB just because I like the simplicity of purpose when it holds nothing other than the data that fulfills my planning needs.

But in either case, create fields for each of the step of the plan. Create views for each step of the plan, showing which databases need that action. I also recommend an overall status view, showing each status field, to give you “the big picture.”
I don’t have a sample DB at the moment to illustrate this, but it isn’t a very complex DB, conceptually. Do what works for you.

Now that you have the inventory DB, the trickier part is getting the data in place. It is not rocket science, just some basic scripting. My recommendation is a nightly agent that loops through every DB on the server, creating a document in the inventory for each DB found. (And updating if it already exists.)
I recommend this agent gathers, at a minimum the following data for each DB:

• Title
• Filepath
• Server
• ReplicaID
• ACL Managers (this data may help in IDing the business owners)

One the DB is created and the data is in place, you are ready to move on to the next step of the plan.

But — let me point something out here. As the migration moves forward, and more and more apps are no longer in Notes, will your team really want to keep coming to Notes just for the migration tracking DB? Doubtful. There are two ways to mitigate this. The quick and easy one is to just make this a web interface and be done with it. Everything above still applies if you do this.

But let’s have some fun for a moment. Let’s consider what it would take to make that exact same tracking DB in Sharepoint:

1. Create a custom list in Sharepoint, with the fields listed above and the status fields.
2. Create a Console App in Visual Studio.NET, using the language of your choice.
3. Add a reference to the Sharepoint DLL.
4. Add a reference to the Notes DLL.
5. Write your code. (Again, not rocket science. You have access to the Domino COM objects in your .NET code now, as well as the Sharepoint API. Use the same obejcts as you would in LotusScript, but instead of creating/updating NotesDocuments, create/update list items in your SharePoint list.)
6. Once your code is tested, place it on your Notes server, and run it as a scheduled task on a nightly basis.

Assuming you already have a comfort level with .NET coding, this probably wouldn’t take more than an hour or two longer than setting up the same process in Notes.

If there is any interest in seeing sample code for step #5, let me know in the comments. I haven’t actually written that code yet, and am short on time at the moment, but if there is enough interest, I’ll sit down and crank it out for you.