As companies are moving the existing legacy application to the cloud and adopt a mobile and social first approach; users are becoming less tolerant of antique interfaces, stand alone applications that lack proper integration, and data in various silos. Today’s companies need modern and easy to use apps that are accessible from any device, consolidated data, easy integration with back office systems, and the ability to innovate & adapt.

 

As part of the journey to modernize the application portfolio, many companies are looking to replace Domino Lotus Notes (DLN)  applications.  These applications range in variety, complexity, and functionality.  Many DLN applications are task and workflow based, which make them ideal candidates to migrate onto the ServcieNow Platform.  In this paper, we describe an approach to migrate your DLN applications onto the ServiceNow Platform.

 

Based on our experience from a large number of DLN to Servicenow Platform migrations, we typically see four phases to migrating your DLN application:

 

Phase 1: Determine Complexity

In this phase you will be working with the process owner of this app.  They should be able to take you through the workflow and use cases for this app.  Don’t worry about solving the technical details at this point, but get the requirements flushed out, and leverage the expertise of the process owner to take notes about where this app can improve when migrated to ServiceNow.

 

I often get asked at this phase – “Does ServiceNow have a tool that lets me migrate my DLN app into ServiceNow automatically?”  There is no migration tool, but what I have found is that most people want to use this opportunity to readdress the implementation of the previously written DLN app, and fix issues with their implementation (not migrate over same problems). 

 

It is at this phase we break down an existing DLN application and really understand what needs to be migrated.  Use this opportunity to rethink how things should be implemented.  Avoid over-engineering and unwanted functionality (process, data, integrations, etc.) to the new Platform. Take note about fields on our forms that are not used, overloaded, or the wrong field type; making our workflow more difficult than it should.

 

I normally like to collect answers to the following questions (thank you to my colleague Frank Schuster for sharing these questions):

  • What is the functional app description?
  • Who is the business owner of the app?
  • What is the business criticality of the app (on a scale from 1-5, 5 being very critical)?
  • What was the usage of the app in the past 3 months?
  • How many Notes databases are required for this app?
  • Are there integrations or messaging involved with this app?  Does the app use Sametime for messaging?
  • What is the current size of the database?
  • What is the number of documents in the database?
  • Does the app use ACL and what does that security structure look like? Who has what roles?
  • Does the app need to be optimized for mobile?
  • Does the app generate Outlook calendar invites?
  • Do we need to migrate the existing data into ServiceNow?

 

Phase 2: Plan for Success

You have a few options to solve your app requirements on the Now Platform.

  1. If things are pretty simple, in terms of data model and workflow, then a catalog item may be the best approach. Catalog items are services that are available to order from a service catalog, and use the out-of-box service catalog request data model. Administrators and catalog administrators can define catalog items, with details such as formatted descriptions, workflow, etc. There is no hard and fast rule here, but it is generally a good idea to keep it simple and clean, and included in the appropriate ServiceNow scope. 
  2. You can also define your own data model, not using the service catalog request item table, and keep things nicely contained within one functional ServiceNow application.  These simple data models are easy DLN migrations, and can be represented similarly to the catalog item (within a service catalog and with their own custom workflow).  The main difference between this type of implementation and a catalog item implementation is usually around licensing.
  3. Ultimately, if what you need to convert has a pretty complex data model, workflow, security, integrations, or other business logic, then you should probably do the implementation as a separate application on the Now Platform.

 

As a best practice you should not create a one to one application in ServiceNow for every DLN application.  In ServiceNow, you have the ablity to create application scopes that represent functional groups.  A functional group is defined in terms of the service you are offering, meaning that a single application may contain several DLN applications in one ServiceNow application scope.  For example, if you have several DLN apps that are used for invoicing, you may want to create one ServiceNow application for invoicing, and combine the functionality of those DLN apps into one Servicenow application scope.

 

Extending Task tables

Another big question to ask at this point is how to extend your data model from the ServiceNow Task table.  Task is one of the core tables provided with Servicenow Platform; it provides a series of standard fields used on each of the tables that extend it, such as the Incident and Problem tables. In addition, any table which extends task can take advantage of task-specific functionality for driving tasks.

 

Once again, we do not have to talk about the implementation details here. We do need to find out if we should treat and use the functionality that ServiceNow gives us around extending the task table.  There is no changing our mind once the table is created, without rebuilding the entire table.  I generally like to introduce some of the features of extending Task, in order to determine if we want to introduce this in our DLN app migration.  There are several out-of-box features you get if your data model extends Task, but there also comes a lot of extra metadata you may not really need. A previous blog post talks about extending the task table here:  What you get by extending the Task table .  If your DLN requires SLAs or Visual Task Boards, then the decision is easy - extend Task.  Look at the provided link and make that determination at this stage in the process.

 

I also like to start mapping parts of DLN to the appropriate ServiceNow application file as we will migrate this DLN app to ServiceNow.  It is much easier to break down functional requirements if we have gone through this exercise up front. We can also identify any gaps in product features at this point, and make the decision if ServiceNow is the right tool for this particular DLN application.  I usually like to categorize my application components into three main categories:

  1. Data Model
  2. Display
  3. Code

 

Data model

The data model from DLN will include tables, fields, files, and data relationships.  This maps pretty nicely into ServiceNow as a table, with the appropriate fields and security.

 

Display

The User Interface from DLN will include forms, views, navigators, and web pages, and these will map into UI Pages, Catalog Items, Portals, Process State Flows, Dashboards, Reports, and Related List in ServiceNow.

 

Code

The code from DLN will include formulas, LotusScript, Java, JavaScript, and other API calls. This will map into business rules, workflow, script includes, and events within ServiceNow.  All of the coding for converting these DLN files will be done in JavaScript on the ServiceNow Platform.  With the exception of Web Pages (which use HTML, CSS, etc) all of the implementation in ServiceNow is done in JavaScript.

 

Phase 3: Build and Test for Quality

Once you know what needs to be built, and we have a migration plan, the implementation isn’t too hard to do. I usually start building the data model first.  Most of the functionality in ServiceNow is data driven.  What I mean by this, is that once we create the right table structure ServiceNow will autogenerate APIs, List views, and Forms based on the data model.  This can all be done with no code in the ServiceNow Platform, saving quite a bit of development time.

 

After all of the tables are created, I start to tweak the out-of-box List and Form views of our newly created table.  Remember these forms are autogenerated by ServiceNow.  Once again we can do this without code.  I usually like to insert some sample data and create some reports and dashboards in this phase as well as use our out-of-box Service Portal if a more modern single page application is necessary.

 

Lastly I tackle the business logic.  This is where I build out the workflow and reimplement the coding details given from the DLN side of things. Understanding the process at this point is imperative.  Do you need approvals for a particular request? Do you calculate data when a particular database trigger is fired?  Do we need to implement a particular integration with an external system?  All those requirements are addressed in this phase.

 

Ultimately, you do not have to follow these steps exactly. You may find yourself bouncing around these steps, but as a best practice it is important to test frequently along the way.  What I mean is that you implement a functional requirement and test, then implement another requirement then test.  These tests are not a full test, but small functional test based on the feature you currently implement.  Once you feel your application is in a good state, then you can publish to a Test instance of ServiceNow and do a full end to end test with real production data, etc.  Depending on the complexity of app you may have multiple deployments of an app (resulting in more than one version before it is pushed to production).  It is recommended that you use GIT as a repo for this ServiceNow application, as it facilitates the management of these versions.  It is also a best practice to do all code changes and development on your ServiceNow development instance and not on your test/QA or production instances.

 

Phase 4: Deploy into Production

At this point in the migration we are ready to get our application into the hands of our customers (internal or external).  As a best practice I like to deploy frequently.  Do not be afraid to get your application into production and start getting feedback from your user base.  ServiceNow has a feature for publishing applications to a private repository for your company domain.  It is through this publishing your other instances will have access to the install or update your newly created app.  The length of time to convert a DLN app depends on the complexity of what we are converting.  You may find yourself publishing multiple applications a day and some that may take a week.

 

This paper is only the beginning of what you can do once you convert an app from DLN into ServiceNow.  There are many features within the ServiceNow Platform we did not get into, but can be utilized to enhance your DLN application from then to NOW!

 

Feel free to contact me at: chris.maloy@servicenow.com