Migration Considerations for Re-Platforming Applications on Nintex

Given the rise in popularity of Office 365, the imminent release of the next iteration of SharePoint on premise, the number of companies now feeling the balance has tipped in favour of upgrading to SharePoint 2013 vs. remaining on their heavily customised SharePoint 2007/2010 environments, the number of organisations now on the hunt for a new forms solution since Microsoft’s announcement that InfoPath is to be retired…<long sentence. breath>…it’s no wonder that I’m having more and more conversations with organisations about where to start with their potential migration.

So in answer to those questions and conversations, I’ve put together a short paper on my thoughts as to how you would go about planning such a thing. I’m coming at this subject from the business applications angle, hence the use of ‘re-platforming’ in the title of this post. That’s not to say many of the things covered wouldn’t apply to a ‘standard’ SharePoint migration; SharePoint is, by definition, a business application.

But if I’m not simply ‘lifting and shifting’, aren’t I re-platforming?

At the bottom of this article I’ve attached the paper as a pdf, so you can take it away with you on holiday or perhaps pin it to the wall of your bedroom like a Spandau Ballet poster…or whatever you fancy doing with it. Not that I’m judging, but alternatively you could just read it on screen.

There’s a comments box at the bottom of the page for making notes in, or adding tracked changes.

1. Abstract

There are a number of considerations when re-platforming business applications to the Nintex Automation Platform. The following article will discuss those considerations in brief, and provide a checklist of activities to undertake and questions to ask as part of planning for migration.

2. Overview

The word ‘re-platforming’ is used to describe the activities and preparatory work required to successfully migrate a solution to a Nintex Automation Platform from a non-Nintex related platform.

NOTE: The re-platforming concept also applies to the migration of applications using earlier versions of Nintex and where a reorganisation of content is required. This is also the case for migrations from an on premise Nintex and SharePoint instance to Office 365.

The following are examples of re-platforming scenarios:

  1. Migration of Lotus Notes Applications to SharePoint and Nintex on premise
  2. Migration of Lotus Notes Applications to Office 365 (O365) and Nintex
  3. Migration of SharePoint and Nintex applications to the current releases (where content reorganisations is required)
  4. Migration of SharePoint and Nintex applications from any version of O365 and Nintex
  5. Migration of other Line of Business (LoB) applications to on premise SharePoint and Nintex or O365 and Nintex

For all scenarios above, a hybrid approach to the destination platform can be considered (SharePoint on premise, O365 and Nintex)

3. The Re-Platforming Approach
3.1. Audit and Classify

The first step for any re-platforming activity it to understand what it is that you intend to migrate. A thorough inventory of existing applications, their components and dependencies, is essential to the planning process.
Microsoft has produced a great deal of resources relating specifically to migrations from Lotus Notes to SharePoint platforms that serve as a good starting resource for creating you application inventory – http://technet.microsoft.com/en-us/library/aa998110(v=EXCHG.65).aspx

Figure 1 - Microsoft - Domino Application Framework (Quadrants)

Figure 1 – Microsoft – Domino Application Framework (Quadrants)

The diagram (Figure 1) above gives a starting point for application classification in Lotus Notes/Domino and will inform the migration approach, migration tools required and timescales.

For a more detailed analysis, the following specifics should be recorded:

  • General

    • Application Name
    • Business purpose
    • Last accessed date
    • Last modified date

  • People

    • Owner(s)
    • Contributors
    • Consumers
    • User Access Control (security)

  • Data Layer

    • Data structures
    • Data volume (at rest)
    • Data volume (in transit, active applications)
    • Data Connections (LoB integration points)

  • Process Layer

    • Workflows (scheduled or ad hoc)
    • Manual steps
    • Integration and data schedules

  • User Interface

    • Structured data capture layer (forms)
    • User interfaces (screens)
    • Reporting

The importance of capturing information about, and understanding the purpose of, your business applications is paramount if you are to answer the following questions on an application by application basis:

  • Is this application actively used? (or just referenced?)
  • Does this application replicate the functionality of others?
  • Can this application be consolidated with others?
  • How important is the application; should it be high or low priority?

As a further source of reference look to the ‘Microsoft Application Analysis Envisioning Process’, which outlines their four phase approach to identifying and classifying applications (specifically Lotus Notes/Domino) – http://technet.microsoft.com/en-us/library/aa997497(v=exchg.65).aspx

NOTE: Whilst much of this article refers to Lotus to Microsoft technology migration, the same approach can be taken to the re-platforming of any LoB application on SharePoint and Nintex.
3.2. Segment, Analyse and Plan

Once classification has taken place, with each application segmented into groups, specific migration approaches can be targeted at each.

One group will likely have a lightweight migration requirement, relying on simple data mapping and migration with the use of an appropriate third party migration tool.

Others will require more in depth analysis to determine the right migration approach.

Again, Microsoft have done some excellent thinking around this subject in the ‘Microsoft Application Analysis Envisioning Process’, where the Phase 2 goal in determining appropriate criteria can be applied to the differing application groups:

  • Leave in place criteria
  • Buy versus build criteria
  • Evaluate existing deployed software
  • Evaluate e-mail system
  • Evaluate Directory
  • Business function and functionality reviews
  • Is this application actively used? (or just referenced?)

Detail can be found here – http://technet.microsoft.com/en-us/library/bb124869(v=exchg.65).aspx

Whilst the decision to migrate applications to the Nintex Automation Platform has already been made, the criteria above will help focus effort on the key priorities and structure a phased approach to delivering the migration (i.e. there may be merit in leaving the low priority solutions ‘in place’, or not migrating them at all)

An approach to address each application group will need to be documented and used to define the appropriate migration order and timeframes.

3.3. The Project Plan

Having segmented, analysed and defined the approach(es) to application migration, a plan needs to be created.

Each project is different with timescales driven by myriad financial, business and market factors. As such, the intention is not to prescribe a template approach to the migration plan, rather highlight questions and discussion point that should be considered in its creation.

3.4. The Questions

  1. When are you starting the project? (not the actual migration, but initial planning)
  2. How long do you expect to spend in planning?
    1. Building the migration v-team
    2. Analysis and inventory of source environments/applications
    3. Identification of different types of applications, sites and content
    4. Development of information architecture for target environment with associated content mapping
    5. Preparation of pre-migration remediation plan
    6. Preparation of post-migration remediation plan
    7. Preparation of proof of concept plan
    8. Preparation of test criteria and test scripts
    9. Preparation of migration ‘roll back’ plan
    10. Preparation of communication and adoption plan
  3. Will you be creating new applications, sites and apps in the target environment immediately, or continue to provision on premise assets throughout the migration?
  4. When will the project proper start?
  5. When will project communication start?
  6. How long will pre-migration remediation take?
  7. How long will you spend to proof of concept/testing of the migration process?
  8. What migration tools are you planning to use?
  9. When will you kick off the actual migration of content?
  10. How long do you anticipate the migration taking?
  11. How long will post migration remediation take?
  12. When will you be fully operational in the target environment?
  13. Place your list items here

4. Summary

The importance that auditing and classifying the target business applications plays in answering the questions posed in section 3.4 should not be underestimated. Having a comprehensive understanding of the answers to those questions will ensure the project plan is correctly aligned to business requirements, resource availability and dependencies.

Segmenting applications into groups and performing deeper analysis on the ‘Process Centric’ and ‘Custom Applications’ group (Figure 1, quadrants 2-4) is key to identifying the right tools for migration and the right order in which to migrate.

EXAMPLE: Two business applications based on the Lotus Domino platform have been identified for re-platforming on the Nintex Automation Platform. As part of the analysis phase it is identified that, whilst both have equal business importance, migration of one application will necessitate the use of a feature available in the next product release – scheduled for 3 weeks’ time. Migration priorities can now be effectively planned and correctly communicated to the business.

Failure to adequately analyse and plan, ahead of the first piece of data being migrated, risks unnecessary pressure being placed on the migration process and conflicting project communication inhibiting end-user perception and adoption of the final platform.

It is hoped that discussion points in this article will help project teams establish the project plan and likely timeframes upon which key activities are based early on in the migration process – timeframes that inform key project activities such as vendor engagement, procurement and stakeholder communication.

Appendix 1 – Additional References
Reference Number Publisher Name Description Resource Type Location
REF0001 Microsoft Application Coexistence and Migration Microsoft documentation targeted and migration form Lotus Domino/Notes to SharePoint Web page Link
REF0002 Microsoft Application Analysis Envisioning Process Summary landing page for detailed process overview Web page Link
REF0003 Kimmo Forss Channel 9 Landing page Kimmo Forss is a key contributor to the community on the subject of migration Web page Link
REF0004 Kimmo Forss Assessing Customer Environments: Preparing to Upgrade or Migrate to SharePoint 2010/SharePoint 2013 SPC2012 session on assessing environments ahead of any migration Video Link
REF0005 Kimmo Forss Assessing Customer Environments: Preparing to Upgrade or Migrate to SharePoint 2010/SharePoint 2013 Presentation from REF0004 PowerPoint Link
REF0006 Kimmo Forss Migrate your data and documents efficiently to SharePoint Online and OneDrive for Business SPC2014 session on migration considerations to O365 and OneDrive for Business Video Link
No comments yet.

Leave a Reply