I vote for Henrik Lausten to win the prize. His was a simple, eloquent way of stating, "If it ain't broke, don't fix it."

1. What criteria do you use to determine whether an app should be migrated to XPages?

At the moment it is only worth "migrating" if it is to be delivered exclusively via a Browser. The beta versions of 853 ( as demonstrated at LS11 ) show promise but 852 is not suitable for client based apps running from a server.

It is only worth "migrating" if there is significant value to be had - this means it needs to be re-written anyway to add significant functionality or to improve the user experience or to allow delivery via a browser.

It is only worth migrating if you are making a long term commitment to XPages in terms of skills - it is too steep a learning curve to make it worthwhile for a small one-off project.

2. Which apps should never be considered for migration to and/or developed using XPages?

Client only apps ( as of the current release )

Interaction with mail is difficult - I am not sure how we would replace CRM type systems which typically create a memo in the back end, add some filing data and then surface it as a draft email in the mail client.

We are actively avoiding rich text in XPages at the moment as exporting rich text into MS office etc.. is harder in XPages

Very cheap and cheerful apps - they are quicker and better in classic Notes.

3. When should a hybrid approach be considered which adds XPages to new/existing Domino apps?

For New
When users need to use the client against a server ( as of 852 ) as well as browser
To avoid the constraints listed in 2)

For Existing
When bringing new users into an existing app via a browser
Specific functionality that cannot be achieved in Classic Notes

As a network manager with an admin background I would probably say that XPages migrations most likely occur with a core app that the customer needs web access or wants a new UI. Never migrate anything you don't get paid to migrate. And lastly if you have a recent, say R7 app, but need some additional functionality you can add the XPages.
But in general none of our clients want Notes apps, its all for the web and mobile or don't bother them.

1. After spending almost 2 years migrating a huge application with both Notes client and web access and finding out at the very end that XPiNC has performance issues and that there are fundamental changes to how it behaves (eg no drag selection, paging which does not allow for selection and retention from multiple pages for those documents to be acted upon), I would, in future, only migrate web apps to xPages.
2. Apps that are heavily used on the Notes client. For the above reasons.
3. Hybrid is a good question, because the reason I like xPages is that a single xPage can be developed for use on both the web and in the Notes client. But I would have chosen to make the application I just changed over as a hybrid, knowing what I now know. Another really important reason that I DID use xPages for this app is because it was huge and the xPages technology allowed me to split out the data from the design, and create viewPanels with data from multiple sources. That is really cool!

1. It's really a question of cost over benefit. If users currently access via the Notes client and will continue to do so, it can be hard to sell the cost of migrating when performance of XPiNC is not great and they do not want to take advantage of functionality improvements. I'm looking for where additional benefits can be delivered as a hook into XPages - mobile, reporting etc For existing web apps, with huge script libraries, it's not a massive effort to convert LotusScript functions to Java or SSJS. What is a huge effort is adding good error handling to all your classes/functions/subs, changing all the forms and views to XPages, getting them to look the same because of XPage-related CSS conflicts, testing, QA, UAT etc. If you've got to support web and client interfaces, once XPiNC performance issues are addressed, there's real benefit. Regardless of all this, I would never just convert, always re-develop, which means changing functionality to produce a user experience more appropriate to XPages. Good XPages development gives a different user experience to traditional Domino web or Notes client user experience. Trying to reproduce Notes client functionality on XPages is a recipe for pain.

2. Again, as a BP the customer is the deciding factor, since they usually have to pay. I would probably steer clear of extremely complex, very stable, un-touched applications that will only ever be accessed via the client, UNLESS there are significant and comprehensive functionality enhancements which can be sold to the customer. Again, that doesn't mean an XPages interface couldn't be added for specific functionality.

3. When the application is web, complex, works acceptably, the customer is new to 8.5 and doesn't know why they would want to use XPages, but has new requirements. Show them the power of what can be done in XPages to merge information from multiple views/database or to perform back-end processing quicker and more efficiently. Educate them on different navigation or editing approaches that are more appropriate for XPages. As ever, without user buy-in, you're doomed.

1. Apps where there is a demonstrable business value from the conversion: the inclusion of new/changed functionality, a need for an improved and/or browser-based UI, a corporate or application need to move away/not support from the Notes client, better performance, etc etc.
2. Apps that have no UI: there are plenty of code-heavy transaction oriented apps with no UI around - data integration apps, mass email apps and so on and so forth.
3. When there is a good business case. One Xpage app I've done has a significant end-user UI that was converted to Xpages, and an admin UI that is used by a small number of people on an occasional/irregular basis to manage the app. There's no serious business case to migrate that admin interface. It might have been 30% extra cost for no significant benefit, given the small number of users of it vs the 000's of users of the end-user UI.

1. If every user in our environment needs to access the app, its going to be an XPages app as the browser is the easiest delivery tool we have.

2. I wouldn't say never, but there are some apps that are working as is and I do not have the time to migrate them to XPages.

3. I would consider a hybrid approach for applications that need to be accessed by all my users but some users have more rights than others. For example, we have a Performance Review application and I am currently putting an XPages front-end on it so our associates can sign, view, and complete peer reviews. Evaluators need more functionality and that functionality currently exists in the Notes client for this application. These users also have several other apps and are "office workers" and will always have the Notes client. XPages allows me to quickly make this application accessible, with only the access and functionality they need, to our basic users anywhere they have an internet connection.

1. All my Apps have been Notes Client Apps. So all have been candidates to make them more accessible to people on the go via a web browser. That apps that I had that required off line access were candidates for XPiNC. Though heavy testing of XPiNC would be required.

2. Apps that have a stagnant feature set, or are using some of the rich client hooks should either be left alone or at least investigated last. Spend time where the biggest gains are. I'm not sure I know of a good example of what should never be developed with XPages.

3. A hybrid approach should ALWAYS be considered when you have an existing Notes Client app. If the app is working. Then freeze the notes client feature set and start to add new features to an XPage version and add existing features as time permits until you achieve parity. But you might want to take a more aggressive approach if it makes sense to change the data modeling of the app to something more relational and less conducive to the Notes Client.

1. If someone says they want an XPage application and if it only runs in an Intranet/LAN environment
2. In theory all apps have to be converted at some point because the classic environment is not going anywhere. I know of apps that have been in constant development for more than 10 years. It will be a difficult and troublesome task to migrate them to XPages. Those will probably move to another technology.
3. In its current state I would never consider a hybrid approach unless the application does not contain Rich Text items or is a pure browser application.
4. The Amazon gift certificate should go so someone else please.
It would be nice to know why you are asking those questions?

1. If the app has any web audience, or if features need to be added where the development ROI would highly benefit by using XPages functionality such as repeat controls, etc. Any app with a large amount of shared controls that would be better implemented by custom controls.

2. Any apps where the server is pre-8.5.1FP3. Any apps on an 8.5.2 (no fixpack) server. Any apps that need to be used with DOLS, or any apps where offline performance is extremely important - the thick client's offline speed is pretty bad, and with no DOLS support XPages offline capabilities are generally hobbled. Any apps with heavy C api-use and/or richtext, encryption (NSF-level), COM. Any apps with massive Lotuscript libraries where the rewrite to SSJS/Java is too expensive to develop and test (thanks, .recycle!)

3. Always, assuming your Notes/Domino versions line up with #2 above. A major benefit of XPages is their capability to coexist with classic design elements.

Hi Bruce

1. Don't focus on migration options but rather on new functionality. So if an app is already a web app and introduces a fair amount of new functionality, it should be considered for migration to XPages

2. Stable apps (whether Notes client apps or web apps) with no changes to functionality coming up. So don't migrate for the sake of migration only.

3. A hybrid approach makes sense when existing Notes client apps need to have a web interface. A hybrid approach also makes sense when admin users are Notes client users already. Then all admin functionality can be implemented using Notes client functionality while XPages is used for the web presence.

1) if it is webapp and if it handles a lot of data in views so using AJAX makes it less "bandwitdh hungry". OR if customer asks for it :-)
2) until 8.5.3 is out with preloading XPages runtime and/or databases on notes client startup, all non web application. And all applications that use COM, OLE and so on.
3) see #1

1. When it makes commercial business sense to do so.
2. When it doesn't make commercial business sense to do so.
3. When it makes commercial business sense to do so.

(wish I lived in a world where apps could be migrated just because they could be)

1) Need for centralization, renovation and redesign :)
2) None :) But applications with rich text usage, encryption needs and those being used locally could wait for another year.
3) To speed transition, generic ui can be transferred to XPages. Meanwhile, advanced users, operators and database admins may continue to use old interfaces with complicated functions...

1. All applications that need a face/function lift
2. Applications relying on heavy use of RichText, Signature and Encryption
3. For #2 apps and for applications where the web part works well (why upgrade if is looks good/works well) Also in transition. Rome wasn't build in one day

1. It's in active use.
2. Applications with heavy reliance on client-side integration, such as heavy use of COM and/or custom C code
3. Depends completely on the organization's tolerance for risk vs. return and whether they have effective governance processes.

1. When ever you CAN migrate, then you should migrate
2. If it interacts with the mail interface, example, "create work order from this email", or deals with allot of rich text.
3. When only a subset of features are required for mobile or web. Approve this type thing ....Add a comment

Ok, I've thought long and hard about this...

1. If it's a Notes App, it should be migrated to an XPages App
2. None, please see # 1.
3. If you haven't completed your R8.5.x upgrade yet and still have applications on pre-XPages servers.

How's that?

;-)