Metastorm BPM 7 to 9 Migration

119c2299-fb17-4a54-9a81-929bf009ac36

Migration

Code Migration

Implementation

Migration

Planning Team

Accountable

System Owner

The business owner of the system. This could also include any number of interested stakeholders.

Project Manager

The Project Manager for the Migration project

Testing Team

Accountable

Project Manager

The Project Manager for the Migration project

Tester

Testers of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

Development Team

Accountable

Developer

The developer of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

Team Leader

The Development Team Leader

Database Team

Accountable

Database Administrator

The DBA responsible for the Metastorm BPM databases

Developer

The developer of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

Development & Testing Teams

Accountable

Developer

The developer of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

Team Leader

The Development Team Leader

Tester

Testers of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

SME

Subject Matter Experts. These are typically 'power users' and administrator users of the Metastorm BPM systems.

Implementation Team

Accountable

Project Manager

The Project Manager for the Migration project

System Administrator

The System Administrator responsible for the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

Owners

Accountable

System Owner

The business owner of the system. This could also include any number of interested stakeholders.

Initiate Migration

Plan Migration

This migration is a two-part migration. Firstly the code is migrated, and then validated and fixed to work in version 9. Then the data itself can be migrated. When complete, this can then all be tested and fixed as needed. This is not a simple process. If tackled correctly, it should be successful. If it is not, you can waste a lot of time, effort and money fixing mistakes that have been made.

Things to consider

Before developing plans, it is best to consider several aspects of the migration and new system.

Staging

Consider if the processes will all be migrated at one time, or separately. If separately, consider whether they will run ‘side by side’ or in separate environments.

You will need to make sure that all dependant Process are migrated at the same time if you are performing a staged migration.

Make sure that all stakeholders understand that there must be a code-freeze in the current system until migration is complete. As this can take several months, it is important that it is understood right from the start. If there are any changes required for any reason, make sure that it is understood that all changes to the existing system will need to be applied and tested in the new system as well.

New Functionality

Consider if you will be making use of new functionality. If you are interested in the multi-language capability, for example, you should set this up when installing, as it is much simpler at that point.

Other considerations may be to simplify or redevelop processes or forms. Of course, this will involve analysis and design tasks, but these may be quicker and more effective than testing and fixing existing functionality that has become over-complicated.

InputsRolesSystemsLocationsOutputs
        • Project Plan (information)

        Split to Test Plan and Code Migration

        The Test Plan building can happen independently while the code is being migrated from version 7 to version 9.

        Build Test Plan

        It is essential to develop a proper Test Plan for your migration. If there is no proper plan, then the migration will likely fail, even if in small and non-critical ways. The overall effect will probably cause a reduction in confidence of the system, and even the platform itself (Metastorm BPM).

        A well-designed and well-executed Test Plan will very likely prevent this and promote confidence.

        Test Cases should be well thought out. The most valuable resources when building these are probably expert users of the system. Find out what problems have occurred in the past, and what scenarios are likely to generate problems. From these discussions, test cases could be generated.

        Another important consideration that is often overlooked is test cases for data. The existence and accuracy of at least sample sets of data should be checked. Reports compared between systems can be very effective to manage this.

        InputsRolesSystemsLocationsOutputs
            • Test Plan (information)

            Code Migration

            The Code migration has been split into several activities in a sub-process. Click on the '+' to open the sub-process for more information.

            InputsRolesSystemsLocationsOutputs
            • Version 9 Solution Files (information)
            • Version 7 Procedure Files (information)
                • Version 9 Solution Files (information)
                • Version 7 Procedure Files (information)
                • File Migration Mappings (information)

                Join from Test Plan and Code Migration

                At this point the Test Plan will be needed

                Migrate Data & Update

                Once the Projects are deployed, you can start the data migration. This allows the data migration to be tested on the current Production data, and gives you an opportunity to test the functionality with existing data.

                WorkInstructions

                This will typically be managed using the Data Migration tool. This can be done one Process at a time, but you will need to make sure that all dependant Process are migrated at the same time if you are performing a staged migration.

                There may be issues with the data after migration. It is not possible to specify all possible issues, but we have not yet come across any system where nothing needed to be updated.

                It is important to keep all of the SQL used to update data, and keep these as scripts to execute after the full data migration.

                InputsRolesSystemsLocationsOutputs
                • File Migration Mappings (information)
                • Test Plan (information)
                  • SQL Scripts (information)

                  Test & Fix Code & Data

                  Now that we have both the code and the data migrated, we can start testing the functionality.

                  WorkInstructions

                  Functional Replication

                  This seems as though it may be overkill, but we have found that the best way to test functionality of processes is to perform a set of actions in version 7, then to try the same activity in version 9 with the same data.

                  In one system we migrated, the business users actually set up the data migration test to occur just before their regular monthly cycle of activity. They then ran the exact same actions in the version 9 system just as they were being executed in the version 7 system, against the same data but migrated. The result was a very thorough set of tests without the need for extensive Test Cases. Bear in mind that Test Cases will still be required, this won’t catch everything!

                  Test Cases

                  Finally, once the test data is all migrated, you can start on the test cases you previously generated. Note that quite different errors may be generated. It is worth noting that the errors reported in the Designer log may be difficult to fathom too. Along with validation, these really need to be made at least as good as they were in version 7 to be properly useful.

                  InputsRolesSystemsLocationsOutputs
                  • Version 9 Solution Files (information)
                  • Test Plan (information)
                    • Version 9 Solution Files (information)

                    Implementation

                    Once the Code and Data are both validated and tested and are deemed accurate, you can then plan the final phase where the data is migrated from the existing system to the new system. Obviously the code should not need any more work, but the data will have been updated since you started the code migration and data migration testing.

                    The Implementation has been split into several activities in a sub-process. Click on the '+' to open the sub-process for more information.

                    InputsRolesSystemsLocationsOutputs
                    • SQL Scripts (information)
                    • Version 9 Solution Files (information)
                    • File Migration Mappings (information)

                          Review

                          InputsRolesSystemsLocationsOutputs

                                Migration Complete

                                SQL Scripts

                                SQL Scripts

                                All SQL scripts used to update the migrated data in any way

                                Version 9 Solution Files

                                Version 9 Libraries & Projects

                                The mappings files generated by the Metastorm BPM 9 File Migration tool

                                Version 7 Procedure Files

                                Version 7 Library & Procedure Files

                                These are the Library and Procedure files from the version 7 system

                                File Migration Mappings

                                Migration Mappings files

                                The mappings files generated by the Metastorm BPM 9 File Migration tool

                                Project Plan

                                Project Tasks & Timings

                                The project plan covers the entire migration from end to end. This will contain the Implementation Plan in draft form. The Implementation Plan will be finalised during the Implementation dry run.

                                Test Plan

                                Functional Test Cases

                                A detailed set of test cases and plan to utilise them. This should include functional all areas.

                                Data Test Cases

                                A detailed set of test cases and plan to utilise them. This should include all required data validation such as reports.

                                Code Migration

                                Development Team

                                Accountable

                                Developer

                                The developer of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

                                Team Leader

                                The Development Team Leader

                                Start

                                v7 Code Review

                                Before the file migration, the existing version 7 code should be examined for potential changes and improvements that are not as straightforward after the file migration.

                                WorkInstructions

                                Code freeze

                                It may seem obvious, but business users need to be aware that the code will have to freeze during the code migration phase. This means no new features. If anything needs to be updated to fix faults or meet legislative changes, everybody needs to be aware that the changes will need to be applied and tested in the version 7 code, and again in the version 9 code.

                                Procedure Files

                                One thing we have noticed is that the version 9 Designer can struggle when there are a lot of components in a Project (previously called a Procedure). It is definitely wise to consider breaking up large Procedure files before migration as well, as Projects will be migrated as a whole. Having smaller Projects will also give you more chances of finding and fixing any faults during both file and data migration.

                                If any components are shared, it is well worth putting them in a library accessible to all necessary Projects. Components such as Flags and Roles are probably the most likely candidates.

                                This should be done before the files are migrated. After migration, there can be significant issues managing the renaming of Projects.

                                Grids

                                The most important thing to do is to make sure that all grids are named appropriately. If, like us, you were a bit slack at naming grids, you will end with a whole load of meaningless names for Business Objects. Naming the grids will ensure that Business Objects are also sensibly named after migration, making debugging and maintenance a great deal easier.

                                Make sure your grid columns are using the correct case. In version 7 and before, the code managing this was case-insensitive. In version 9, just about everything is case-sensitive. This is possibly only important when using Oracle as a database, as it always returns uppercase names by default regardless of the columns in the select statement used.

                                Flags

                                Note that Flag parameters are now strongly typed in Version 9. In previous versions you could pass in different parameters and types for each flag call. You can no longer do this in version 9, so you need to make sure Flag parameters are consistent across the system for each Flag.

                                InputsRolesSystemsLocationsOutputs
                                • Version 7 Procedure Files (information)
                                  • Version 7 Procedure Files (information)

                                  Migrate Code

                                  Now the code gets migrated. This involves use of the File Migration tool.

                                  WorkInstructions

                                  Save all the libraries and procedure files.

                                  For all file migrations we recommend not to create large solutions with many Libraries and/or Projects. Ideally, in our experience, you should have one Project or Library per Solution. In some rare instances, it may be appropriate to have a Library and a Project. There is no benefit to grouping Projects in a Solution.

                                  Migrate all the libraries first. These will need to be validated and deployed. If they cannot be deployed, the migration of any Procedure files relying on these libraries will not work.

                                  Now migrate the Procedures. Remember to keep the ‘Mappings’ file. There is also an HTML file produced explaining any renaming or other changes performed. This could be essential, although it is typically rather lengthy.

                                  In each File Migration, you will need to be aware of several faults in the generated systems. We will not be publishing this here, but will be willing to provide consulting on the issues you will need to be aware of.

                                  InputsRolesSystemsLocationsOutputs
                                  • Version 7 Procedure Files (information)
                                    • Version 9 Solution Files (information)
                                    • File Migration Mappings (information)

                                    v9 Code Review

                                    After the file migration, the migrated code should be examined for potential changes and improvements.

                                    WorkInstructions

                                    Processes

                                    Processes are generally the same in version 9 as previous versions. The one difference is the use of Sub-Processes (previously Map Segments). The data for these is stored in a separate table. You may need to consider how that will affect any data lookups or reports you may have.

                                    You may be able to make use of the new ‘only show action if’ property of Actions. This can reduce the need for complex dynamic roles that we had to employ to hide or show Actions under certain conditions.

                                    Forms

                                    Make use of Local variables where necessary. These variables exist for the life of the form, and will not be saved to the database. Using these can allow you to remove any number of redundant ‘temporary’ variables you may have been forced to create in previous versions.

                                    You need to be aware that some Forms will need to be reformatted. There are two main changes to fields that can force this. The first is the space required for an asterisk before required fields. This can move a caption further to the left, potentially overlapping other fields. The second is that grid column titles and rows are taller. This can make grids difficult to navigate until they are expanded.

                                    You may be able to make use of the new ‘only show form if’ property of Forms. This can reduce the need for complex dynamic roles that we had to employ to hide or show Forms under certain conditions.

                                    Meta-script

                                    Note that all code that relies on string matching will now be case-sensitive. In previous versions it was all case-insensitive. In version 7 it is also possible to use the ‘greater than’ and ‘less than’ comparisons for strings. This is no longer possible in as it is not possible in C#. You would have to add your own function or find a different way to achieve your goal.

                                    Any code that references Metastorm internal data may need updating. The most common of these are likely to be Process (Map), Stage, Action and Role names. All of these may need to be updated as spaces are replaced with underscores. Note that there may be other renaming due to naming conflicts (eg all actions have to have a unique name) and reserved words.

                                    Note also that some replaced features will not work as they did in version 7 and earlier. We do have a few functions in our library that replicates these built-in functions while fixing them.

                                    Server Scripts

                                    Most server scripts we have created are in Jscript. This works well, as the transition from Metastorm Jscript to C# is not complex. The code structure is similar, although it is obviously a ‘real’ language with more stringent rules, and is also very strongly typed.

                                    VBScript is not so easy to convert to C#, and you have no alternative to doing this manually. Developers familiar with both languages are useful if this is required.

                                    Jscript.Net is probably the easiest to convert to C#. Although the parameter passing construct was exceedingly awkward in JScript.net server scripts in Metastorm BPM 7, the language itself is very similar to C#.

                                    Client Scripts

                                    From our experience, many client scripts will need to be, or would certainly benefit from being, rewritten. If you have many of these, and they are in any way complex, you should consider this carefully.

                                    If you access any part of the Metastorm BPM form using any method that is not part of the standard supplied and supported functions, you will definitely have to rewrite these.

                                    Given the much more extensive functionality in Metastorm BPM 9, it is often worthwhile abandoning Client Scripts in favour of real code. There are still a few instances where these are still required, such as setting cookies and copying text to the clipboard.

                                    Grids

                                    If you have any ‘dynamic SQL’ grids, these need special consideration. These are typically used for query forms, and involve building the SQL in code to get the required results. Most of these will require Scripted Business Objects to be built. These are not intuitive, and are code-intensive. They are very powerful, however.

                                    Other SQL

                                    Across all the code, you should see how much database access and updating is performed in your system. If there is a lot, for example to update read-only grids or even for dropdown option lists, you may need to edit quite a lot of the migrated code.

                                    To make best use of the Metastorm BPM 9 database access functionality, you would also need to parameterise these where possible.

                                    You need to be aware that any SQL that references Metastorm internal data may need updating. The most common of these are likely to be Process (Map), Stage, Action and Role names. All of these may need to be updated as spaces are replaced with underscores. Note that there may be other renaming due to naming conflicts (eg all actions have to have a unique name) and reserved words.

                                    Roles

                                    As noted in the Forms and Processes sections, some Roles may be simplified or even removed by using the new ‘only show if’ functionality for both Forms and Actions.

                                    InputsRolesSystemsLocationsOutputs
                                    • Version 9 Solution Files (information)
                                      • Version 9 Solution Files (information)

                                      Redesign

                                      This point is a very good time to consider alternative designs and additional functionality. Metastorm BPM 9 has a very different architecture to Metastorm BPM 6 or 7. In this section, we list the various main areas of interest.

                                      WorkInstructions

                                      Process Design

                                      You may be able to take advantage of the use of Captions to replace Stage and Action names. These can contain characters that were not allowed in version 7, for example. You can also give two Stages or Actions the same caption, although this can potentially become confusing, so must be used carefully.

                                      Note that Actions now have a description. This appears as a tool-tip popup in the client when you hover over the Action. This can be used to document the Process more effectively.

                                      Form Design

                                      Forms are very similar in version 9, but they do have some very important new features. These mainly involve panels, which can be docked, and the fact that all fields can be resizable as the Form size itself is changed. You may want to discuss how they can be taken advantage of once the migration is complete.

                                      You may be able to take advantage of the use of Form Captions to replace Form names. These can contain characters that were not allowed in version 7, for example. You can also give two Forms the same Caption.

                                      Code Reuse

                                      The proprietary code format of Metastorm BPM 4, 5, 6 and 7 has been dubbed ‘Meta-script’ by many. Most of us know that this can become unwieldy at times, and may well look forward to a neater and more functional code structure that a language such as C# can offer. As a C++ and Java developer myself, I have found the transition welcome and easy. Many may find that getting to grips with a real programming language a bit daunting. Concepts such as classes, casting, loops and use of arrays are not simple concepts. Some of the errors generated by incorrect syntax can be highly confusing, for example.

                                      Since we had no ability to create reusable functions (except using server scripts) in Metastorm BPM 7 and before, we tended to duplicate a lot of code. We have also seen this many times in systems written by others. It is very much worth seeing how much can be made reusable if you have any duplication.

                                      Most of the changes allow a far greater use of reusable code and shared components. To make best use of these, you may want to consider redesigning the way code is managed.

                                      As an example, we now recommend having all code for a Project in Server Scripts. This prevents the need for hunting through myriads of different components to find references. Since all functions can easily be promoted to The Visual Script Toolbox, you can simply add these to each event to replace code. You could then never have to open the event for any component again. This also gives you much better scope for collaborative development between Process Designers and Developers in the future. See details in our Training Courses.

                                      If you make use of Web Services, you can make a lot of use of the new Connections in version 9. These allow you to use Web Services much more effectively. Most, if not all, of the existing code to manage these may be redundant now.

                                      Common Business Objects

                                      Consider the number of grids you have, and how complex they are. If you have a great many, you will end up with a large number of Business Objects. It is worth considering how much of this SQL it will be possible to reuse in common Business Objects.

                                      Database Updates

                                      Database access in version 9 can be very much simplified in a number of ways. The most prominent of these is the use of editable Business Objects. We often read from and update tables other than the main process table during key processes. In order to do this in version 7, we used to have to select multiple fields, assign values, and then write values back to the database.

                                      In version 9, it is quite possible to use any Business Object as the main source of data in a form, and even in a process. This can be as simple as setting the default parameter, and then using the fields from the Business Object in a form directly, or even in process events. Values assigned to these Business Object variables will be saved when the activity completes. You would not need to do anything at all in terms of SQL to maintain this data, as this is all handled at the Business Object level.

                                      InputsRolesSystemsLocationsOutputs
                                      • Version 9 Solution Files (information)
                                          • Version 9 Solution Files (information)

                                          Validate Code

                                          You now need to validate the code. This involves validation in the Designer, and then and deploying the migrated Projects.

                                          WorkInstructions

                                          Validate Code

                                          The first test is to validate the code. This can throw up some confusing errors, so you will need time and patience. The error reporting in version 9 has come under a lot of fire for being unhelpful and difficult to understand. Often every single reference throws an error, so you have hundreds of them, which is almost useless. We agree that this is probably the weakest feature of Metastorm BPM 9, and one that needs to be fixed as soon as possible.

                                          Deploy Code

                                          When you have eliminated all the errors generated by the validation, you can attempt to deploy. This may throw up quite different errors. It appears that the validation in the Designer is different to the validation in the Deployment service. In some cases this is understandable, but in others it is not.

                                          InputsRolesSystemsLocationsOutputs
                                          • Version 9 Solution Files (information)
                                            • Version 9 Solution Files (information)

                                            Version 9 Solution Files

                                            Version 9 Libraries & Projects

                                            The mappings files generated by the Metastorm BPM 9 File Migration tool

                                            Version 7 Procedure Files

                                            Version 7 Library & Procedure Files

                                            These are the Library and Procedure files from the version 7 system

                                            File Migration Mappings

                                            Migration Mappings files

                                            The mappings files generated by the Metastorm BPM 9 File Migration tool

                                            End

                                            Implementation

                                            Implementation Team

                                            Accountable

                                            System Administrator

                                            The System Administrator responsible for the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

                                            Database Administrator

                                            The DBA responsible for the Metastorm BPM databases

                                            Start

                                            End

                                            Build Implementation Plan

                                            Once the Code and Data are both validated and tested and are deemed accurate, you can then plan the final phase where the data is migrated from the existing system to the new system. Obviously the code should not need any more work, but the data will have been updated since you started the code migration and data migration testing.

                                            InputsRolesSystemsLocationsOutputs
                                                  • Implementation Plan (information)

                                                  Test Implementation

                                                  Note that we recommend this entire process is performed as a ‘dry-run’ to test that it works as planned. There may be many involved parties, and many steps and resources involved. It is a good idea to act this out, taking timings all the way. This then ensures the process will work, and that you can plan the times well.

                                                  Note that as some tasks may take many hours, these should be set to be started overnight if time is constrained. This can ensure a minimal down-time of the system.

                                                  WorkInstructions

                                                  In Advance

                                                  Create new system & database

                                                  Consider whether you will want multi-language capabilities now or in the future. If so, it is much better to set this up right from the start rather than add it later.

                                                  Deploy Solutions

                                                  Deploy all the version 9 libraries and projects to the new system. Note that the Engine must be running for this.

                                                  Shutdown v9

                                                  Shut down the version 9 Engine and Deployment services. Make sure these are set to ‘Manual’ start, just in case the server is rebooted, even accidentally.

                                                  On the Day

                                                  Shutdown v7

                                                  Shut down the version 7 Engine service. Make sure this are set to ‘Manual’ start, just in case the server is rebooted, even accidentally.

                                                  Migrate data

                                                  Migrate the data as done previously.

                                                  Execute SQL scripts

                                                  Execute al the SQL scripts generated in the data migration and subsequent tests.

                                                  Test data

                                                  Perform any tests on the data that you have generated to ensure that the data has been migrated successfully.

                                                  Start Version 9

                                                  Start up the version 9 engine. Check that folders open, and blank forms and actions can be started. There should be no need to submit any actions to perform this test.

                                                  Examine Designer Log & Event log

                                                  Examine the Designer Log and Event Log for any errors. There may be issues such as system actions that have failed that are not otherwise evident.

                                                  InputsRolesSystemsLocationsOutputs
                                                  • Implementation Plan (information)
                                                  • SQL Scripts (information)
                                                  • Version 9 Solution Files (information)
                                                  • File Migration Mappings (information)
                                                    • Implementation Plan (information)

                                                    Implement

                                                    Perform the Implementation as per the plan

                                                    WorkInstructions

                                                    In Advance

                                                    Create new system & database

                                                    Consider whether you will want multi-language capabilities now or in the future. If so, it is much better to set this up right from the start rather than add it later.

                                                    Deploy Solutions

                                                    Deploy all the version 9 libraries and projects to the new system. Note that the Engine must be running for this.

                                                    Shutdown v9

                                                    Shut down the version 9 Engine and Deployment services. Make sure these are set to ‘Manual’ start, just in case the server is rebooted, even accidentally.

                                                    On the Day

                                                    Shutdown v7

                                                    Shut down the version 7 Engine service. Make sure this are set to ‘Manual’ start, just in case the server is rebooted, even accidentally.

                                                    Migrate data

                                                    Migrate the data as done previously.

                                                    Execute SQL scripts

                                                    Execute al the SQL scripts generated in the data migration and subsequent tests.

                                                    Test data

                                                    Perform any tests on the data that you have generated to ensure that the data has been migrated successfully.

                                                    Start Version 9

                                                    Start up the version 9 engine. Check that folders open, and blank forms and actions can be started. There should be no need to submit any actions to perform this test.

                                                    Examine Designer Log & Event log

                                                    Examine the Designer Log and Event Log for any errors. There may be issues such as system actions that have failed that are not otherwise evident.

                                                    InputsRolesSystemsLocationsOutputs
                                                    • Implementation Plan (information)
                                                    • SQL Scripts (information)
                                                    • Version 9 Solution Files (information)
                                                    • File Migration Mappings (information)

                                                        Implementation Plan

                                                        Implementation Tasks & Timings

                                                        The detailed implementation plan (part of the main Project Plan)

                                                        SQL Scripts

                                                        SQL Scripts

                                                        All SQL scripts used to update the migrated data in any way

                                                        Version 9 Solution Files

                                                        Version 9 Libraries & Projects

                                                        The mappings files generated by the Metastorm BPM 9 File Migration tool

                                                        File Migration Mappings

                                                        Migration Mappings files

                                                        The mappings files generated by the Metastorm BPM 9 File Migration tool

                                                        Roles and Responsibilities

                                                        The Accountabilities table shows the activities and deliverables for which each role is accountable.

                                                        The RACI Analysis table shows the roles which are Accountable, Responsible (actively involved in), Consulted and Informed for each activity.

                                                        System Owner

                                                        The business owner of the system. This could also include any number of interested stakeholders.

                                                        Responsible for: Build Implementation Plan, Review

                                                        Project Manager

                                                        The Project Manager for the Migration project

                                                        Responsible for: Build Implementation Plan, Test Implementation, Implement, Plan Migration, Implementation

                                                        System Administrator

                                                        The System Administrator responsible for the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

                                                        Responsible for: Test Implementation, Implement, Implementation

                                                        Database Administrator

                                                        The DBA responsible for the Metastorm BPM databases

                                                        Responsible for: Test Implementation, Implement, Migrate Data & Update, Implementation

                                                        Developer

                                                        The developer of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

                                                        Responsible for: v7 Code Review, Migrate Code, v9 Code Review, Redesign, Validate Code, Migrate Data & Update, Test & Fix Code & Data

                                                        Team Leader

                                                        The Development Team Leader

                                                        Responsible for: v7 Code Review, Redesign, Build Implementation Plan

                                                        Tester

                                                        Testers of the Metastorm BPM 7 and/or the Metastorm BPM 9 systems

                                                        Responsible for: Build Test Plan, Test & Fix Code & Data

                                                        SME

                                                        Subject Matter Experts. These are typically 'power users' and administrator users of the Metastorm BPM systems.

                                                        Responsible for: Build Test Plan, Test & Fix Code & Data

                                                        Deliverables

                                                        The Deliverables table shows the activities which produce and consume each deliverable.

                                                        SQL Scripts

                                                        All SQL scripts used to update the migrated data in any way

                                                        Implementation Tasks & Timings

                                                        The detailed implementation plan (part of the main Project Plan)

                                                        Migration Mappings files

                                                        The mappings files generated by the Metastorm BPM 9 File Migration tool

                                                        Version 9 Libraries & Projects

                                                        The mappings files generated by the Metastorm BPM 9 File Migration tool

                                                        Version 7 Library & Procedure Files

                                                        These are the Library and Procedure files from the version 7 system

                                                        Functional Test Cases

                                                        A detailed set of test cases and plan to utilise them. This should include functional all areas.

                                                        Data Test Cases

                                                        A detailed set of test cases and plan to utilise them. This should include all required data validation such as reports.

                                                        Project Tasks & Timings

                                                        The project plan covers the entire migration from end to end. This will contain the Implementation Plan in draft form. The Implementation Plan will be finalised during the Implementation dry run.

                                                        Systems

                                                        Version 7 System

                                                        The Metastorm BPM version 7 System. This can refer to any environments (Dev/Test/Prod), but will in the main only involve the Production database (or a copy of this).

                                                        Version 9 Development

                                                        The Metastorm BPM 9 Development system

                                                        Version 9 Test

                                                        The Metastorm BPM 9 Test system

                                                        Version 9 Production

                                                        The Metastorm BPM 9 Production system

                                                        Version : 2.0

                                                        Status : APPROVED

                                                        Modified :

                                                        Security :

                                                        Executive Summary:

                                                        The support for version 7 of Metastorm BPM is nearly at an end. Many customers have version 7 systems. Many even have version 6 systems still running. These will need to be migrated to Metastorm BPM 9. As well as allowing continued support, this allows supporting platform software that also has run out of support life to be discarded in favour of newer supported software.

                                                        The real problem many are facing is working out how to manage this. As a provider of Metastorm BPM services and solutions for 12 years, we have a large number of migrations between Metastorm BPM systems under our collective belts. In recent years, these have all been conversions from Metastorm BPM 6 and 7 to Metastorm BPM 9.

                                                        Migration to Metastorm BPM 9 is not as simple as previous versions. Effectively, the platform itself has been completely altered. Although Metastorm did a very good job of making the Designer and Client look and work at least similarly to previous versions, under the hood it is a very different beast. Because of this, the system cannot be updated ‘in situ’ as before, but must be migrated.

                                                        This migration is a two-part migration. Firstly the code is migrated, and then tested and fixed to work in version 9. Then the data itself can be migrated. This is not a simple process. If tackled correctly, it should be successful. If it is not, you can waste a lot of time, effort and money fixing mistakes that have been made.

                                                        Confidentiality

                                                        All information in this document is provided in confidence for the sole purpose of adjudication of the document and shall not be used for any other purpose and shall not be published or disclosed wholly or in part to any other party without prior permission in writing and shall be held in safe custody. These obligations shall not apply to information which is published or becomes known legimately from some other source.

                                                        Many of the product, service and company names referred to in this document are trademarks or registered trademarks.

                                                        They are all hereby acknowledged.

                                                        Document Control
                                                        TitleMetastorm BPM 7 to 9 MigrationCode
                                                        AuthorJerome PearceTemplateProcess HTML v5.3.xsl
                                                        OwnerJerome PearceFile Ref.Metastorm BPM 7 to 9 Migration.xbp
                                                        Distribution
                                                        OrganisationAddress
                                                        Jerome Pearce
                                                        Approvals
                                                        ApproverRoleApproved?DateVersion
                                                        Jerome Pearce
                                                        Review
                                                        NameRoleReviewed?DateVersion
                                                        Ruben Lopez
                                                        Jerome Pearce
                                                        Change History
                                                        VersionDateStatusAuthorDetails of Change
                                                        1.021-March-2014draftJerome Pearce

                                                        Initial version

                                                        2.022-March-2014reviewJerome Pearce

                                                        finalised for review

                                                        Copyright © Business Optix Limited 2008-2014

                                                        This table shows the activities and deliverables for which each role is accountable.
                                                        Role Process Activities Deliverables
                                                        System Owner Migration Plan Migration
                                                        System Owner Migration Review
                                                          Project Manager Migration Plan Migration
                                                          Project Manager Migration Build Test Plan
                                                          Project Manager Migration Implementation
                                                            System Administrator Migration Implementation
                                                              System Administrator Implementation Build Implementation Plan
                                                              System Administrator Implementation Test Implementation
                                                              System Administrator Implementation Implement
                                                                Database Administrator Migration Migrate Data & Update
                                                                Database Administrator Implementation Build Implementation Plan
                                                                Database Administrator Implementation Test Implementation
                                                                Database Administrator Implementation Implement
                                                                  Developer Migration Code Migration
                                                                  Developer Migration Migrate Data & Update
                                                                  Developer Migration Test & Fix Code & Data
                                                                  Developer Code Migration v7 Code Review
                                                                  Developer Code Migration Migrate Code
                                                                  Developer Code Migration v9 Code Review
                                                                  Developer Code Migration Redesign
                                                                  Developer Code Migration Validate Code
                                                                  Team Leader Migration Code Migration
                                                                  Team Leader Migration Test & Fix Code & Data
                                                                  Team Leader Code Migration v7 Code Review
                                                                  Team Leader Code Migration Migrate Code
                                                                  Team Leader Code Migration v9 Code Review
                                                                  Team Leader Code Migration Redesign
                                                                  Team Leader Code Migration Validate Code
                                                                  Tester Migration Build Test Plan
                                                                  Tester Migration Test & Fix Code & Data
                                                                  SME Migration Test & Fix Code & Data
                                                                  This table shows the roles which are Accountable, Responsible (actively involved in), Consulted and Informed for each activity.
                                                                  Process Activity Accountable Responsible
                                                                  (involved in)
                                                                  Consulted Informed
                                                                  Migration Plan Migration
                                                                  Migration Build Test Plan
                                                                  Migration Code Migration
                                                                      Migration Migrate Data & Update
                                                                      Migration Test & Fix Code & Data
                                                                      Migration Implementation
                                                                      Migration Review
                                                                      Code Migration v7 Code Review
                                                                        Code Migration Migrate Code
                                                                        Code Migration v9 Code Review
                                                                        Code Migration Redesign
                                                                        Code Migration Validate Code
                                                                        Implementation Build Implementation Plan
                                                                          Implementation Test Implementation
                                                                          Implementation Implement
                                                                          This table shows the activities which produce and consume each deliverable.
                                                                          Deliverable Produced by Consumed by
                                                                          SQL Scripts
                                                                          Implementation Tasks & Timings
                                                                          Migration Mappings files
                                                                          Version 9 Libraries & Projects
                                                                          Version 7 Library & Procedure Files
                                                                          Functional Test Cases
                                                                            Data Test Cases
                                                                              Project Tasks & Timings
                                                                                Loading...