Header Image -

Monthly Archives

3 Articles

LOE Comparison – Notes vs. SharePoint

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info


For those keeping track, our formal strategy on what to do with Notes vs. SharePoint was on hold pending some hard data on the level of effort to develop and maintain applications.

So we did what any group of people without data would do — we made some ourselves. We selected an app that was basic enough to be realistic, but with enough quirky features to throw a wrench at us, and went ahead and made a prototype.

Results were as follows:

  • 1 week to get the development environment all worked out, mostly by finding the right patches for Office and SharePoint.
  • 4 days of learning the various controls and techniques available to us.
  • 1/2 day of actual development once we got it all put together.
  • Approximately 80% of functionality with an exact match, 15% with a reasonable change of function to met the same business needs, and 5% not achievable with a realistic amount of effort.

And we concluded the following:

  • For strategic purposes, we should ignore the 9 days of “learning curve”. That is a one-time effort for each developer, probably decreasing as the team’s skills grow.
  • The actual development effort between SharePoint and Notes is fairly comparable, IF you stick with certain restrictions (listed below). Details of specific apps may make one side quicker than the other, but the delta is small enough that it shouldn’t impact our strategy.
  • Security is weak in SharePoint. Before SharePoint folks jump on this, let me give a caveat to that statement – You can make SharePoint security match every Notes security function short of field-level encryption, BUT that then changes the level of effort significantly. To keep development levels on pace with each other, apps that require complex, strict security need to remain within Notes.
  • You must use InfoPath. We, as developers had decided that InfoPath was nice, but not really needed. But the time savings in development has changed our minds. Without InfoPath, stick with Notes.

The bottom line is this — from a purely technical point of view, migrating to SharePoint is a “neutral” activity. It neither offers great benefit, nor does it offer great harm. The decision is going to be made on a non-technical basis. The cost of running SharePoint is likely higher today, but it will likely come in line over the next couple years as skill sets improve and Microsoft improves the product.
Technical folks will be able to punch holes in SharePoint to their heart’s content… there are enough gaps and issues to do so. However, SharePoint will meet a significant majority of requirements, and the amount of technical effort required to fill in the gaps will be an acceptable risk/cost to most organizations with valid strategic reasons to be moving to SharePoint. In particular, if a small/medium sized Notes environment is kept around for the ~10% of functions that SharePoint cannot handled.

Our overall recommendation in our organization is to do new development in SharePoint, web-enable as much Notes as we can, remove the Notes client from the organizations, and let the Notes system decrease over time through natural attrition, as the SharePoint environment matures.

(Note that this is a change. When I started this blog, the strategy was “Get rid of Notes. Now.”)

This path also leaves us with options – if the platforms undergo major change for better or worse, we can always turn our strategy around.

Getting Started with Notes

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info


A number of bloggers have recently written their stories of how they got started with Notes. I didn’t read them all, but the ones I did read share a common thread, and it is a thread that is applicable to the reasons people are migrating to SharePoint.

Every Notes person I know has been doing it for many, many, many years. I was in a room with about 50 Notes folks on morning, and the presenter asked every who had more than 10 years experience with Notes to raise their hands.
Everyone had a hand raised.

We are an “old” pool of talent. We are highly skilled, but expensive. Young developers don’t usually gravitate to Notes. I say “usually” because there certainly are younger, hipper, people who do Notes work. But they don’t seem to stick with it, and they don’t seem to become the die-hard evangelists that the online community presents.

So its great that we have this well-developed talent. My last few years of work have been with wonderful teams, where any member of the team could have led the team, managed the projects, etc. It made for great working relationships, and we put out great work. I think those teams were worth every penny the customers paid.

But that is exactly the issue – without young, inexperienced, cheap talent… the hiring process for Notes folks tend to be unfriendly to budgets.

So what’s my story?

I started as an end user of Notes, when I got a job at IBM research doing desktop support in 1994.  That job was just a temp contract, so I moved on to an analyst firm, where I did Notes admin for a while. sending their research to customers via Notes replication. (via modems to 300 servers. Ouch.)

Again, that was a short term job, but I then moved to a hospital that was converting from green screen apps to Windows-based apps, and I was able to build up a small Notes environment to track the hardware assets, projects, and helpdesk work.

I then moved back to IBM, helping them roll out Notes internally, and becoming a development team lead for one division. That led to senior develop positions in startup companies for many years, until I got back into the corporate world, being asked to help remove the platform.

The one consistent pattern through all my career has been that of changes in technology platforms. I’ve (almost) always been either building a Notes platform, or removing one.  It is a technology that enables change on a very fundamental level.

Synthesis of Discussions on Notes v. SharePoint

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info


In the past week, I’ve received numerous emails, comments, and reactions to the general concept of migrating Notes to SharePoint.
I wanted to post a brief synthesis of some of the main points, and add some commentary of my own:

1) Notes vs. SharePoint is not comparing apples to apples. Quickr is the better comparison tool.
This is true. However, Quickr does not have the market penetration that Notes in general does. Much as I’d like to say it is a fair discussion for organizations in my situation, unless you already have Quickr going in your environment, it just isn’t realistic. We’re talking about determining the best platform for our current functions, not evaluating a new platform for future collaboration. Quickr just is not a consideration in our current environment, for political, if not technical reasons.

2) Web enabling an entire Notes environment is a difficult, expensive task.

Maybe it is because I’ve been web-enabling Notes apps since the first IBM-internal beta of R5, but I just don’t think it is as difficult as people are making it out to be. There is certainly a large learning curve, but I got over that curve almost 10 years ago. Am I the exception? From all the wonderful tips and techniques offered in the blog-o-sphere, I thought more Notes developers were comfortable in this arena. Is my perception inaccurate?

That being said, I agree that a 100% web enablement would be a chore. We’re more likely to pick the easy apps, and pick the apps with a large user base. If we can web enable enough apps to decrease the number of Notes Clients in the environment, we decrease support and maintenance costs. The more we decrease those costs, the more management will support keeping Notes/Domino as a technology platform.

3) Why would you migrate anyway?

It all comes down to cost. I think everyone will agree that today, Notes is cheaper to run. We already have a talented staff, the environment is stable, we have processes in place, etc. In addition, truly talented SharePoint experts are rare and expensive. A lot of people have it on their resume, but they crash and burn in a real project situation.

So with all that in mind, how can SharePoint save money? People I have spoken with believe that in 3-5 years, the costs will reverse. 3-5 years from now, SharePoint folks will be as common as C# folks are today. Microsoft will have released one or two more major releases, and will respond to the major weaknesses being identified in the platform.

On the other hand, Lotus folks are a dwindling population, at least in my area. I’ve talked to a number of organizations who will accept a greater cost today to get to the platform that they believe will become cheaper as Microsoft responds to the weaknesses of SharePoint, and the talent pool increases their skillsets.

After all the talks, my general strategy hasn’t changed much from one of my previous posts, and it is very close to becoming the official strategy at my workplace:

  1.  Increase the internal skillset on SharePoint, BizTalk, .NET, etc. to reduce the amount of consulting required on the platform.
  2.  Web enable Notes apps, and integrate them with a SharePoint portal, striving for a reduction in Notes client deployments.
  3.  Create new apps in .NET/SharePoint, unless Notes has a clear cost and speed advantage for the specific functions requested.

Let me just add one or two caveats:

  • If you are already on Quickr, your strategy may be different.
  • If you are so large that the enterprise-level weaknesses of SharePoint are unacceptable to you, Notes makes more sense.

And I would like to close with an open-ended question — given the following root causes of the desire of “management” to migrate to Notes…

1) Decreasing Lotus talent pool, and increasing cost of that talent.
2) Confidence that MS will resolve their SharePoint issues, and decrease long-term costs and pains in a SharePoint world.

….What can IBM/Lotus do to turn around migrations like mine?

(From a truly unbiased point of view, I shouldn’t care. But with 15 years of Notes experience, but only 2 years of .NET, and 6 months of SharePoint experience, I just plain got more skillz on the Lotus side, and I’d like to use them.)