Last Planning Post

Based on the stats, you guys care a lot less about planning, and a lot more about technical details.
So be it — one last short post to finish out the plan, then we’ll get more detailed posts coming.

If everything is now scoped out, you have everything you need to prioritize your migration.

Prioritization is going to be based on your business needs, naturally. But let me make just a couple suggestions:

1) Put the apps that require the most maintenance near the front of the list. That will give you an opportunity to correct the problems causing maintenance, as well as leave you with a low-maintenance Notes environment, so you can spend your time on more valuable tasks.

2) Put client-based apps near the front of the list, too. I’ve mentioned before  that simple getting to a 100% web-based environment should offer maintenance and cost benefits to your organization.

The, the final step – do the migration.

I’m not even going to attempt to comment on that. A lot of work to be done. From here on out, I’ll try to continue to post technical issues and techniques. That is where all the fun is to be had anyway.

The Plan – Step 5: Scope each app

This isn’t a topic that needs instruction, hopefully. Most software folks can scope out an app within some measure of accuracy. Most project managers can take weeks of effort to produce detailed analysis and come up with the exact same answer as the software folks pulled out of… the air.

But because we are moving from a pltform that we know very well to a completely different platform, I thought some warnings were in order:

1) Tasks will have a different scope in SharePoint than in Notes. Give yourself maybe 20% more time to do forms work, 30% more time for view work, and 20% less time for UI work.The back-end coding is probably fairly equivalent, even if totally different.

2) Early in the migration, there will be a learning curve. I’d add 100% to the scope of your first app, maybe decreasing by 10% for each successive app until you are really comfortable on the new platform.

3) The best business ROI will not come from a direct migration, but from evaluatiing business processes alongside the migration. Be sure to add extra time into your scope for communications, meetings, analysis, and possible redesign of your apps.

Your scope doesn’t need 100% accuracy at this point. We aren’t budgeting costs here – we are just getting a reasonably accurate sense of effort for each app to assist in our planning. As long as you are consistent in your methodology, you should end up with usable results. We will be using these scopes in prioritizing our efforts, to maximize the benefit to the business. We hyst want enough accuracy that we don’t spend 8 weeks on a project that has a minimal business impact.

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.

The Plan: Step 4… part c… .NET

“.NET Custom Development”

Code geeks, this is where we get to have fun.

You can literally do anything with SharePoint as a front-end by doing custom development in .NET. When Microsoft proponents say that SharePoint is vastly powerful, this is what they are talking about.

But let me explain exactly what your options are within .NET: You can write web parts in .NET. You can write pages and forms in .NET, you can customize your existing SharePoint lists in .NET. You cna write huge, massive .NET apps and bring them into SharePoint. Hey, its .NET. A full programming environment. You can do it all. And THAT is where Microsoft gets away with saying SharePoint is powerful.

While I agree – this gives you all the power in the world, let us also be clear — you’re no longer working in SharePoint. You are working in ASP.NET, and using SharePoint as a front-end. And it feels like a hack to me — to customize a SharePoint list’s entry form, you open the file system and edit the aspx page. Sure, it works, but it is a hack.

But let me focus on that first part — it works. Quite well. ASP.NET has a lot of power. It is in ASP.NET that Notes people will see the event-driven model they are used to on a form. This is where the full .NET object model is available to you, in addition to the SharePoint APIs, and yes, even the Notes COM objects. Code up some web services around your enterprise, and you can do some VERY slick integration work at this level.
You can code up your forms, write code to handle every possible user interaction with every possible component, and basically start to approach what Notes gives you. You can code console apps and schedule them in the OS, and achieve the equivalent functions of your scheduled agents. (Although, let’s talk maintenance issues some day.)
When you tag SharePoint on to the front to handle UI and Navigation for you, this is when it starts to be a real competitor to Notes.

Let me re-iterate that sentiment, as I think it is one the Notes people need to recognize. SharePoint alone is no match for Notes. But when you throw in .NET coding behind it, it is very competitive with Notes. Even price-wise as the .NET Framework and SharePoint Services are free. (Fancy tools like MOSS, and IDEs do cost money, though.) At this level, .NET can do just about anything Notes can. I am not so sure about field-level encryption or replication, but short of those items? I have confidence in the .NET platform for business application development.

So with those 2 items in mind that SP + .NET are not so good at — let’s get back to the concept of planning. Of the apps you have remaining, how many of them do not need replication or field level security? Before you say “all our folks replicate their data locally”, think about replication for a minute. Replication is much more than offline access to data. It is the algorithms to incorporate that data back into a DB. We can use XML to grant access to .NET data offline. We can even write a simple front-end for the users to use as an admin/edit interface into that data. And writing some basic code to handle updating the source DB with the offline data isn’t rocket science either. What IS difficult is handling replication conflicts.
So let me ask the question again a little differently — which of your apps needs replication conflict handling after offline data processing? I suspect when you stop to really think about this, the number will be greatly decreased. Remember, our goal here is not to sell Domino. It is to figure out how to meet the business goals without Domino, and identify what the true technical issues are.

So where do we now stand? We’ve identified which apps can be placed into SharePoint, and which ones need custom .NET coding. We’ve also probably identified a few that do need some specific Notes features. Let’s hold onto those until we finish the last few options.

My next post will cover our last three categorization options, and then we’ll move on to some planning steps that will take some technical analysis and scoping.  I know I’m talking at a very high level right now, but we’ll get deeper as time goes on… I promise…

The Plan — Step 4: Categorize Each DB… part B

“Leave it in Domino, Front-end exposed through Sharepoint.”

Let me first cover some of the technical aspects here. Getting SharePoint to display a domino app is brain-dead simple. There is a Web Part that will pull another site into your SharePoint interface. Just put in a Domino URL, and you’re done.

But can it really be that easy? Well, no. Most of us who build Domino apps have gotten very good at ViewTemplates, navigation, and all the tricks to wrap a UI around the core functions of your app. But if you do that in SharePoint, you will have dual navigation schemes, and create a horrid UI. Instead, you will want to think about showing just the forms and views the user wants to see. Let SharePoint handle the navigation UI — that is what SharePoint is good at, after all.

What I have done in the past is to create a SharePoint site with minimal left navigation, then created a page with a single web part. I then built a $$ViewTemplate with a list of views in the left navigation of the Domino app, with a content frame to hold the display of views and forms. You can use CSS to make the Domino app match you SharePoint look & feel, and it actually integrates quite nicely.

The web part basically just gives you an iframe in which to house your Domino App. This means watch out for what it does to your back button, and be aware of what you do once a form is submitted. It would be wise to render a response into your frame… don’t redirect the browser to a new page. Otherwise your Domino app could remove the SharePoint interface from the user’s browser.

But aside from those small issues, this is a very quick and easy solution to get a Domino app into a SharePoint portal.

Now the more important question:
Why would you do this? What does it do for you? What risks does it pose?

There are two main reasons to do this:

1) Get rid of the Notes Client — Despite the great work done on Notes 8, the negative aspects of Notes’ reputation are usually pointed squarely at the client. People don’t like it. It also costs money to deploy a thick client, to maintain ID files, to train your support people on Notes, etc. A 100% web-based environment will be easier on both the users and your support organization. You do lose replication, which may be a deal-breaker for some organizations, but if your organization is already moving to SharePoint, they probably have already decided that that is an acceptable loss.

2) Leave yourself a backout plan — Let’s be honest here. Most migrations off of Notes fail once the leadership realizes how much more effort and cost it will take to do the same amount of work in a Microsoft environment. By leaving the core app on Domino, you still have your app in place if your management reverses their strategy.

There are also two main reasons not to do this:

1) It isn’t really a migration — Pushing this option too hard makes it clear that you think the Notes migration is a losing strategy. While I hate office politics, it is clear even to me that this will pit you squarely against some of your management. It could be classified under the dreaded heading of “career-limiting move”. If your migration really is on track to succeed, you have just de-railed its eventual completion. You’d better then consider this step as “Phase 1″, and have a secondary solution in mind to satisfy your business requirements.

2) Dual platforms in one interface are more difficult to support — How many of you have worked in a large enough IT organization that your helpdesk tickets bounce around from one team to the other until someone matches what the user said to the actual app and team that need to take action? Mixing platforms like this can breed such maintenance issues. OK, so that is a fairly minor problem, but I wanted to be balanced and give two reasons for each side of the argument. 

One last question — SharePoint can read XML as a data source, and Domino generates XML. Why not just integrate via XML?

Because SharePoint reads XML — it doesn’t write it. Maybe you could hack something together with Web Services, (and maybe I will investigate that down the road, as the idea is intriguing), but just using the basic functions, this strategy would turn your Domino apps into read-only data sources.  Maybe for some apps, this is appropriate. But there needs to be an interface to update the data to make the app worthwhile. If it truly is read-only data, then it falls into the area that SharePoint does well — document sharing.

The Plan: Step 4 – Categorize Each DB… part A?

Sorry for the horrendous subject line, but this one is going to take a number of posts to get through. I’m just going to cover the easy stuff today.

The idea at this point is to ID, in a very generic sense, a solution for each app. This will not only help you have an idea of what work needs done, but the process of deciding will force you to start the learning curve of the Microsoft Technologies. We’ve already established that SharePoint is really just the front-end and some basic forms. We’re going to need to add on other tools. This is your opportunity to identify what tools you want in you organization, and learn about your choices.

“Convert to Sharepoint”

We already went through identification of all DBs that can function in Sharepoint with the out-of-the-box functions. Tag those to be converted directly. I made it a separate step in the plan instead of covering it here because I find it makes you really think about what SharePoint can do if you do a first pass through your organization with that goal in mind before allowing yourself the more flexible choices. SP won’t do everything for you, but it is quick and easy, and therefore a noble goal if you must migrate off Notes.

“Mail-in DB: Move to Exchange”

Check out your mail-in databases. Odds are, at least some of them have no workflow — they are truly just a shared mailbox. Get those things out of the Notes system. Move them to Exchange with the rest of your email. This isn’t a technical issue, it is a maintenance issue. Having dual mail systems is just a pain. So move everything over.

“InfoPath Forms”

When I wrote this option, I had thought InfoPath was a robust forms/workflow solution on the MS side. But as I’ve learned a bit over the past two weeks, I’m beginning to see that just about every solution will require some custom code. So I’m now questioning this option. I’ll leave it in the list, but my current suspicion is that a strong dev organization doesn’t need this. It is another layer of abstraction over the code, which may be good if you are the kind of shop that outsources everything, but want to keep forms in-house.
You could still mark basic form/workflow apps as InfoPath, but I’d keep an open mind as you go forward as to whether  this is really a valid option for your organization, or if you just want to sit down and crank out some code.
And if anyone out there is an InfoPath expert, I’d love to hear some info on why InfoPath is a better solution than custom code.

Look at that — 415 words, and I didn’t really say a thing. Sorry, tech folks. This one was more just pontificating on my internal thought process than anything tangible. Tomorrow evening’s post should have a bit more weight to it. Check back then…

The Plan: Part 3 – Identify Domino –> SharePoint direct mappings.

Or, as I originally phrased it: Identify whether or not the functions of each database can be mapped to built-in functions of Sharepoint. (That was just a little long for a blog entry title.)

(Technical Folks — here is where we start to get into it.)

We now set out to determine if the out-of-the box functionality in SP will cover all the functions of your Notes apps. First, let’s identify what the out-of-the box functions are. For that list, we will refer to anything that can be done in the browser interface or SharePoint Designer. (Which really does not do much more than UI, sadly.)

• Simple lists consisting of Field/Value Pairs – Check.
• Forms to edit records in those lists – Check.
• Ability to set up multiple views, sorting, additional columns, etc – Check.
• Detailed Security on those Forms – Check.
• Workflow applications – Check.
• Discussions – Check.
• Document Libraries – Check.

Many of your simpler Notes apps, if based on Discussion Templates, Document Library Templates, mailboxes, or very simple form & view apps will translate across… As long as you do not use any of the following features of Domino, which do not have SharePoint equivalents:

• Hide-Whens – Not Available.
• Reader/Author access computed based on document data – Not available.
• Flexible Workflow, sending to different recipients, or selecting a different workflow based on document data – Not available.
• More than 2000 items in a view – Not available.
• Private Views – Not Available
• Agents – Not Available
• Action Bar/Shared Actions – Not available
• I’ll stop here. You get the idea…

So, once all the Notes folks are done laughing at how few Notes apps will really fit the above criteria, let’s think about how this will play out in the real world. Some very basic Notes apps will actually work within the limitations SP will place upon us. But most will use some of the basic functions Notes people take for granted, like hide-whens, but for which SP just has no comparable feature.
Does this mean they cannot be migrated? No. But compromises will be made. Do you really need that action to exist in a toolbar on the form? Do you really need hide-whens at a document level, or can a form redesign give you the same business result? If you have a list of more than 2000 items, can they be moved into folders to overcome that SP limitation?
These are the questions that will require communication with the business owners, and are the primary reason we went through the exercise in Step 2.

My current thought is that discussions, document libraries, mailboxes, and maybe some approval cycles still transfer across directly to SharePoint. The feature sets will differ, but the business goals are still met. I suspect there are custom apps that also will have their business goals met, even if the SP implementation is missing some bells and whistles. Some other apps may need to be split into multiple SharePoint Lists, but the navigation built in to SharePoint may resolve any issue that go along with that strategy.

Us Notes folks really have a choice to make here.
One choice is to stay on your soapbox proclaiming how great Notes is. But odds are, if your organization has already decided to migrate, that choice is political suicide. You’ll be great friends with IBM, and they even have presentations at Lotusphere to help you if you choose to go this route. Best of luck to you. Seriously. If folks like you have more success, maybe migrations won’t be necessary.
But I choose the other route. I choose to follow the direction of my organization’s management. I am a software architect, not an IBM sale rep. Instead of stating that SP cannot match a function in Notes, I choose to get creative and see what SP CAN do to meet the business requirements. To be honest, it is a more satisfying work environment this way. Instead of writing yet another Notes workflow app, like I’ve written for over 10 years, I have to really think about the architecture of my apps, and really communicate with the business to be sure that the new solution will meet their needs. In some cases, we can even change a business process to simplify it to the point that SharePoint is a viable solution, and perhaps gain some ROI at that level.

The conclusion for this step of the plan is simple — Accept that SP won’t give you the functions you want. Spend a night or two ranting and raving about it. Then get over it. Embrace what functions SP DOES have. And then work with your business owners to determine what can be migrated easily.
And know that no matter how hard you try, most of your apps will still need more than this step. We’re just knocking off low-hanging fruit here. Over the course of the next week, I’ll start digging into our other options, including VS.NET coding, which ultimately will be our best friend in the MS world.

The Plan: Part 2 — Identify a business owner for every database.

This one isn’t tricky, but will be critical to your success. For every Notes app, you need to identify who owns it in your business. For the apps that you support all the time, you will already know this. Some apps, IT may own directly. And you can list IT as the owner of any DB that came with the server, as it will be your call when they are no longer needed.

But there will likely be some old discussions or small apps that haven’t been touched in years. Maybe the folks who used them don’t even work there anymore. You STILL need to find a business owner. Someone outside of IT needs to make the decision as to whether old obsolete apps can really be deleted, or if the data needs to be migrated somewhere. Most of the time, IT will already know the answer, but there are those rare occasions that some old dicussion DB held information that a department was holding on to for legal reasons, for example. You may not need to keep the app alive, but you need to work with the business on somewhere to archive the data. Or something along those lines.

So let’s spell out what the business owner will do with you:

1. Assist with communicating any changes to the user base
2. Help determine what action is appropriate for the app (migration, deletion, archive, decommision, etc, etc…)
3. Assist with any requirements needed for the migration
4. Assist with testing
5. Give formal sign-offs on any decisions made during the migration (if you work in a structured shop where sign-offs are required.)

I’ve worked in small shops where one high-level manager was willing to be the business owner for most of the apps. That makes it easy. I’ve also been in shops where just tracking down someone willing to take on that role was a 6 month project. Hopefully you are either small enough that this is an easy question, or large enough that you have structured change management, and therefore already have a list of approvers for any application. Those approvers are likely to either be your owners, or able to tell you who is.

(And if anyone is reading this and thinking, “How could you not know who owns an app?”, believe me — I’ve yet to see a Notes hop that has been around for more than 10 years in which every app is accounted for. Note shops are often a little loose on the process side of things — while that may breed some disorganization, it seems to work well that way.)

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.

Step 1: The Plan.

One of the first things that needs done before migrating off of Notes is to plan the migration.

Sounds obvious, doesn’t it?
But I’ve now worked in three corporations that told me in the interview process that their plans were underway… yet when I started, the plan in its entirety consisted of: “Get rid of Notes sometimes in the next few years.”

(And the Notes people smile and don’t push it because they know that unless someone is planning and directing the effort, Notes will stick around. In addition, it would be difficult for a non-Notes person to know enough details of any given Notes environment to make up a plan, so is it really any shock that migrations don’t have a good track record of success to date?)

At the risk of alienation from the Notes folks, let me lay out how I would create the overall plan.

1. Create an inventory of existing Notes apps.
2. Identify a business owner for every database.
3. Identify whether or not the functions of each database can be mapped to built-in functions of Sharepoint.
4. Categorize each DB by its planned future. I currently have the following potential categories:
   “Convert to Sharepoint”
   “Mail-in DB: Move to Exchange”
   “InfoPath Forms”
   “Leave in Domino, web interface integrated into Sharepoint Web Part.”
   “.NET Custom Development”
   “3rd Party Tool replacement.”
   “Decommission”
   “No Action Required.”
5. Calculate a scope of effort for each item on the list. (Take care to note that scope on many items is not technical at all, but consists of business process change and communications.)
6. Prioritize the list.
7. Do it.

I recognize that this over-simplifies just about everything, but…
I intend to expand on each of these points over the next week or two. So stay tuned. I hope to bring out some discussions as I go into more detail that will be useful to anyone else going through this process.

And maybe even some code to help with analysis… maybe…