Method and program product for costing and planning the re-hosting of computer-based applications

Abstract

Disclosed is a computer-implemented method for estimating at least one requirement for migrating a computer-based application from a source platform to a target platform. The method comprises receiving identifications of respective migration tasks; correlating base costs to respective ones of said migration tasks; receiving identifications of migration attributes that affect migration cost; correlating cost factors to respective ones of said migration tasks, each of said cost factors indicating an amount by which a migration attribute affects the base cost of a migration task; and estimating a cost for each migration task, by applying the cost factors for each migration task to the base cost of the migration task. The method may comprise, separately or additionally, assigning base time requirements to respective ones of said migration tasks; assigning time factors to respective ones of said migration tasks, each time factor indicating an amount by which a migration attribute changes the base time requirement for a migration task; and estimating a time requirement for each identified migration task, by applying all time factors for the migration task to the base time requirement of the migration task. Also disclosed is a computer-readable program product, comprising computer-readable program code means for executing the steps of the invented method, in a manner readily known to those skilled in the art.

Description

BACKGROUND OF THE INVENTION

[0002] 1. Technical Field of the Invention

[0003] The invention relates generally to the field of methods for re-hosting computer-based applications. More specifically, the invention relates to a method and program product for costing and planning the re-hosting, or migration, of computer-based applications from source computer-based platforms to target computer-based platforms.

[0004] 2. Description of Related Art

[0005] The use of computer systems and applications greatly simplifies the storage and processing of data. Nevertheless, the large volume of data that a business processes in a short time period can cause the business to become entrenched in its use of a particular platform or computer-based environment. By the time a significant advance is made, the business may be so mired within an antiquated system that it is forced to lose money each year due to the inefficiencies of the system. In response to this problem, methods and systems for migrating applications among computer-based platforms have been developed.

[0006] Re-hosting applications from a source platform to a target platform can be expensive, but a time typically arrives when the cost of continuing inefficiencies outweighs the cost of migration. A business must be able to determine when it reaches this condition, in order to obtain the most benefit from its time and monetary expenditures on a migration. Nevertheless, while methods for migration have grown, businesses have been unable to estimate the cost for migration of applications within useful tolerances. Hence, businesses are prone to waste their resources by significantly undershooting or overshooting the point when migration becomes a cost-effective solution.

[0007] In addition to the cost of a migration project, a business also needs to allow for downtime and other lapses in its application and computer system operations. Again, current migration methods overlook this logistical question and only focus on the end result. A business undergoing migration can suffer needlessly, then, due to an inability to plan precisely for the length of interruption in its operations. This adds to the true cost of migration, forcing some businesses to undergo migration of applications either sooner, or later, than it becomes cost-effective.

[0008] As a result, there exists a great need in the art for a method of estimating the cost of application migration, on a per application basis, within specified tolerances. Additionally, there is a great need in the art for a method of estimating the time required for application migration, on a per application basis, within specified tolerances. The method must provide a thorough analysis of factors that affect the cost and time required for the migration of individual applications, in order to overcome the inconsistencies and inaccuracies of ad hoc plans and cost estimates.

SUMMARY OF THE INVENTION

[0009] The current invention is directed to a method of estimating the cost of application migration, on a per application basis. The invention is also directed toward a method for estimating the time required for application migration, on a per application basis. The method provides allows varying degrees of thoroughness in its analysis of migration attributes that affect the cost and time required for the migration of individual applications between platforms. In this way, the invention produces consistent and reliable results with a degree of accuracy that is genuinely valuable to the particular user.

[0010] The current invention provides a computer-implemented method for estimating the cost and/or time requirements for migrating a computer-based application from a source platform to a target platform. The invented method comprises the steps of receiving identifications of said migration tasks; correlating base costs to respective ones of said migration tasks; receiving identifications of migration attributes; correlating cost factors to respective ones of said migration tasks, each cost factor indicating an amount by which a migration attribute changes the base cost of a migration task; and estimating a cost for each migration task, by applying all cost factors for the migration task to the base cost of the migration task.

[0011] The migration attributes that may be considered in estimating cost may comprise one or more attributes, such as hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, complexity attributes and testing attributes, as further described herein. One or more of the base costs and cost factors may be received from a user.

[0012] The invented method may also comprise applying tolerances to one or more of the estimated costs and total cost, such that one or more of these is returned as a cost range. At least one assessment type may be chosen or defined by a user, such that the assessment observes the user's desired degree of accuracy for the total cost and the cost of each migration task.

[0013] The invented method may comprise, in addition or in the alternative to cost estimation, steps for estimating time requirements for a migration. The steps required for estimating time may comprise correlating base time requirements to respective ones of said migration tasks; correlating time factors to respective ones of said migration tasks, each time factor indicating an amount by which a migration attribute changes the base time requirement for a migration task; and estimating a time requirement for each identified migration task, by applying all time factors assigned to the migration task to the base time requirement of the migration task.

[0014] The migration attributes that may be considered in estimating time requirements may comprise one or more attributes, such as hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, complexity attributes and testing attributes, as further described herein. One or more of the base time requirements and time factors may be received from a user.

[0015] The invented method may also comprise applying tolerances to one or more of the estimated time requirements and total time requirement, such that one or more of these is returned as a time range. At least one assessment type may be chosen or defined by a user, such that the assessment observes the user's desired degree of accuracy for the total time requirement and the time requirement for each migration task.

[0016] Where both time and cost for each migration task and/or for a total migration are estimated, they may be output on a common assessment.

[0017] Individual aspects or functions of the invented method may be embodied in computer-readable program products. Hence the current invention is also directed to computer-readable program code means for implementing and executing the steps of the methods disclosed, in a manner that will be readily known to those skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] FIG. 1 is a flow diagram illustrating the invented method, wherein a cost and/or time estimate for the migration of an application from a source platform to a target platform is output.

[0019] FIG. 2 is an illustration of an example embodiment of an assessment template.

[0020] FIG. 3 is a flow diagram further illustrating steps of the invented method, wherein a Type C assessment is output, in accordance with the current invention.

[0021] FIG. 4A is an illustration of an example embodiment of a base cost matrix.

[0022] FIG. 4B is an illustration of an example embodiment of a complexity cost factor matrix.

[0023] FIG. 5 is an illustration of an example embodiment of a hardware cost factor matrix.

[0024] FIG. 6 is an illustration of an example embodiment of an OS cost factor matrix.

[0025] FIG. 7 is an illustration of an example embodiment of an application cost factor matrix.

[0026] FIG. 8 is an illustration of an example embodiment of an environment cost factor matrix.

[0027] FIG. 9A is an illustration of an example embodiment of a base time requirement matrix.

[0028] FIG. 9B is an illustration of an example embodiment of a complexity time factor matrix.

[0029] FIG. 10 is an illustration of an example embodiment of a hardware time factor matrix.

[0030] FIG. 11 is an illustration of an example embodiment of an OS time factor matrix.

[0031] FIG. 12 is an illustration of an example embodiment of an application time factor matrix.

[0032] FIG. 13 is an illustration of an example embodiment of an environment time factor matrix.

[0033] FIG. 14 is a flow diagram illustrating steps of the invented method, wherein a Type B assessment is output, in accordance with the current invention.

[0034] FIG. 15 is an illustration of an example embodiment of a code cost factor matrix.

[0035] FIG. 16 is a flow diagram illustrating steps of the invented method, wherein a Type A assessment is output, in accordance with the current invention.

[0036] FIG. 17 is an illustration of an example embodiment of a code time factor matrix.

[0037] FIG. 18 is an illustration of an example embodiment of a testing cost factor matrix.

[0038] FIG. 19 is an illustration of an example embodiment of a testing time factor matrix.

DETAILED DESCRIPTION OF THE INVENTION

[0039] Referring now to the drawings, the invention is directed to a method for costing and planning the migration of an application among computer-based environments. The individual steps of the method are preferably executed by at least one computer software program embodied on a computer-readable medium, without regard to the operating system of the computer or the language of the software programs. It will be appreciated by those skilled in the art that some steps of the method may be performed in series, and some in parallel or in series. Additionally, the order of the steps may in some instances be changed, without departing from the scope or advantages of the current invention. The order in the following embodiments is given only for ease of explanation.

[0040] FIG. 1 is a flow diagram illustrating a method for costing and planning the migration of an application from a source computer-based environment to a target computer-based environment, in accordance with the current invention. In accordance with step 101, a set of base variables is received. The base variables comprise an application to be migrated, a source platform on which the application currently operates, and a target platform for the application.

[0041] In accordance with step 102, an assessment type is received. The assessment types are referred to herein as Type C, Type B, and Type A assessments. An assessment may comprise a cost estimate, a time estimate, or both cost and time estimates, for migrating the application from the source platform to the target platform. Assessment types may be delineated by the type or amount of information processed, in order to calculate the cost and/or time estimate returned by the assessment. Assessment types may also be delineated by the degree of accuracy in cost and/or time that the assessment is intended to entail. For purposes of this description, assessments are delineated by their intended accuracy, and, hence, by the type and amount of information gathered.

[0042] In accordance with step 103, an identifier for at least one migration task is received. The migration tasks may be user-defined, or they may be chosen from a list of pre-defined migration tasks. Alternatively, a set of migration tasks may be associated with each assessment type, such that they are received automatically upon receipt of an assessment type. The individual migration tasks involved in migrating a specified application from a particular source platform to a particular target platform are readily known to those skilled in the art. Such migration tasks may comprise, for example, system building, project management, ramp up, baseline testing, migration of the application from the source platform to the target platform, system testing after migration, delivery of the migrated application, acceptance testing to validate that the application can process data, project completion and sign-off, exporting data from the source platform and importing the data to the application on the target platform, redirecting user terminals to the target platform, replacing third party products that cannot be ported to the target platform, and any other individual migration tasks that may be involved in the migration of a computer-based application from a source platform to a target platform.

[0043] In accordance with step 104, at least one assessment template may be created. An assessment template contains the names of the individual migration tasks that will be involved in the migration, cross-referenced to the costs of such migration tasks. The migration tasks may also be cross-referenced to time requirements for each migration task, such as duration of each task in work hours or days, and start and finish times. The migration tasks may be cross-referenced to any other information suitable for the planning and costing of individual migration project tasks. In one embodiment, the assessment template comprises a form, such as that shown by FIG. 2. Those skilled in the art will appreciate that this embodiment of the template is illustrative, and that other templates, including relational and associative forms may be used without departing from the scope of the invented method.

[0044] The assessment template may be created upon receiving a plurality of migration tasks. Alternatively, an assessment template may be chosen from a plurality of pre-defined templates, each containing a different subset of migration tasks.

[0045] The cost of each migration task in the assessment template is shown in a column separate from that of the migration tasks, such that each cost is represented in the same row of the template as the migration task to which it corresponds. For purposes of this description, the cost of each migration task ‘i’ will be represented by the function ƒ(ci). The variable ‘i’ may actually be represented as a priority number or any other suitable number for sequentially identifying the migration tasks represented in the assessment template, such that the total cost of the migration process can be achieved by summing the costs of migration tasks, 1 . . . i.

[0046] The template may also include a breakdown of costs, such as labor and materials, with or without reference to specific tasks.

[0047] At least one time requirement for each migration task in the assessment template may be shown in a column separate from those of the migration tasks and costs, such that a time requirement is represented in the same row of the assessment template as the migration task to which it corresponds. For purposes of this description, the time requirement for each individual task will be represented by the function ƒ(ti). The variable ‘i’ may actually be represented as a priority number or any other suitable number for sequentially identifying the migration tasks represented in the assessment template, such that the total time for the migration process can be achieved by summing the time requirements for migration tasks, 1 . . . i. Where both time and cost are estimated on the template, the variable ‘i’ shall be identical for both ƒ(ti) and ƒ(ci).

[0048] In accordance with step 105, a base cost is assigned to each migration task. Where time is being estimated, a base time is assigned to each migration task. The base cost comprises the average base cost for the migration task, when migrating the application received in step 101 between the source and target platforms received in step 101. The base time comprises the average base time requirement for the migration task, when migrating the application received in step 101 between the source and target platforms received in step 101. Base costs and base times may be user-defined; may be chosen from a database; or may be automatically assigned from a database upon receipt of the base variables. Base costs and base times may vary depending upon the type of assessment to be returned.

[0049] In accordance with step 106, attributes relevant to the migration are received. Migration attributes may include hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, testing attributes, or any combination of these. The various migration attributes are described in further detail below.

[0050] For each migration attribute received, a cost factor is assigned to each identified migration task, in accordance with step 107. Each cost factor represents the amount by which the attribute changes the base cost of a migration task. Where time is being estimated, a time factor is assigned to each migration task. Each time factor represents the amount by which the attribute changes the base time of each migration task. Cost and time factors may comprise proportions that are greater than, less than, or equal to, one. Cost and time factors may be input by users; they may be chosen from a database of cost and time factors; or they may be automatically called from a database in the forms of cost and time factor matrices relevant to the attributes and base variables, as further described below.

[0051] In accordance with step 108, the cost factors assigned to each migration task are applied to the base cost for the migration task, as further described herein. This results in an estimated cost for each migration task. Time factors assigned to each migration task are applied to the base times for the migration task, as further described herein. In accordance with step 109, tolerances may be applied to the cost and/or time for individual migration tasks. The cost and/or time for the migration tasks are then summed to achieve a total cost and/or time requirement for the migration. Finally, in accordance with step 110, an assessment of the type received in step 102 is output, containing the estimated cost and/or time requirement for the migration. The assessment may conform to the assessment template created in step 104, if any. The estimates for cost and time may comprise fixed numbers or ranges. The assessment may also contain cost and/or time estimates for individual migration tasks, which estimates may be fixed numbers, ranges, or a combination of fixed numbers and ranges.

[0052] The steps of the invented method are described in further detail below, with specific references to the different types of assessments and the assignment of base costs and times, and cost and time factors.

[0053] FIG. 3 is a flow diagram illustrating a method for returning a Type C assessment for the migration of an application from a source platform to a target platform, in accordance with the current invention. In accordance with step 301, base variables are received, which comprise an application to be migrated, a source platform on which the application currently operates, and a target platform on which the application is to be re-hosted.

[0054] The application variable may comprise a specific application name and version. Alternatively, the application may include the function of the application and (if more than one function) its component parts, such as production control, batch processing, data mining, online transaction processing (OLTP), or other functions. In the preferred embodiment of the invention, the application variable comprises the name, version and function(s) of the application and its component parts.

[0055] The source and target platform variables may comprise any platforms suitable for operating the computer-based application to be migrated. These platforms may include, for example, UNIX (generic or variants), OpenVMS, IBM AS/400 or iSeries, HP 300 MPE, IBM Mainframe, and other platforms that are readily known to those skilled in the art.

[0056] In accordance with step 302, a user's choice of a Type C assessment is received. In accordance with step 303, an identifier for at least one migration task is received, as described with reference to FIG. 1. In accordance with step 304, an assessment template may be created in the manner described with reference to FIG. 1. The assessment template for a Type C assessment preferably comprises a high-level representation of migration tasks, as distinguished from a Type B or Type A assessment template. A Type C template may also comprise just a total figure for cost and/or time.

[0057] In accordance with step 305, base costs and/or times are assigned to each migration task. For a Type C assessment, the base variables are preferably compared with at least one base cost matrix in a database. Each base cost matrix sets forth an average base cost for migration tasks, such as those listed previously. A base cost matrix may conform substantially to that shown in FIG. 4A, wherein migration tasks are listed in one column, and a base cost is shown in the row containing a migration task to which the base cost corresponds. A base cost, iβ, is extracted from the database, for each migration task, ‘i’, received in step 303. Note that each base cost matrix may contain base cost data for more migration tasks than are received in step 303.

[0058] Each base cost matrix may set forth average costs for migration tasks, with respect to specific applications. Alternatively, each base cost matrix may set forth average base costs for migration tasks, with respect to the degree of commonality of various applications. For example, base cost matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the cost of at least one migration task.

[0059] Where time requirements are being estimated, base time requirements are assigned to each migration task. For a Type C assessment, the base variables are preferably compared with at least one base time matrix in a database. Each base cost matrix sets forth an average base cost for migration tasks, such as those listed previously. A base time requirement matrix may conform substantially to that shown in FIG. 9A, wherein migration tasks are listed in one column, and a base time requirement is shown in the row containing a migration task to which the base time requirement corresponds. A base time, iT, is extracted from the database, for each migration task, ‘i’, received in step 303. Note that each base cost matrix may contain base time data for more migration tasks than are received in step 303.

[0060] Each base time requirement matrix may set forth average time requirements for migration tasks, with respect to specific applications. Alternatively, each base time matrix may set forth average base time requirements for migration tasks, with respect to the degree of commonality of various applications. For example, base time matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the time requirement for at least one migration task.

[0061] In accordance with step 306, at least one migration attribute is received. The migration attributes may comprise, for example, hardware attributes, current operating system attributes, attributes of the application to be migrated, environment attributes, or testing attributes. Hardware attributes include elements of source and target platform hardware architecture, which affect the complexity of migrating an application or porting data between the source and target platforms. Examples of hardware attributes may include, for example, clustering, disks, external interfaces, archive media, memory, networking, media, processors, terminal types (e.g., dumb, emulated), workstations, third-party hardware elements, byte storage sequence (e.g., big endian, little endian) and other aspects of hardware architecture that impact the process of migrating an application or porting data a source platform and a target platform.

[0062] Operating system attributes may comprise the type and version of the source platform's current operating system(s).

[0063] The application attributes comprise attributes of the application that may affect the cost and plan for migrating the application, other than the overall function(s) of the application. Application attributes may comprise, for example, whether the application is real-time; mission critical; user interactive; used for production control, batch processing, data mining, on-line transaction processing (OLTP), or other relevant attributes that may affect the cost and plan for migrating the application. Application attributes may be expressed in descriptive form, or as yes-no (or other analogous binary system) indicators for pre-defined attributes.

[0064] Environment attributes may comprise any attributes of the software environment, in which the application is operated on the source platform, that may affect the cost or plan for migrating the application. Environment attributes may comprise, for example, development languages; databases and other data storage and access attributes; user interfaces; communication transport protocols; networking attributes; shell script usage; security attributes; batch processing characteristics; and other attributes of the software environment in which the application is operated on the source platform, that may affect the cost or plan for migrating the application.

[0065] Testing can be used as a measurement of progress during migration, and it can limit debugging time afterward. Testing itself, however, can have a significant impact upon the time and cost for a migration. Testing during a migration may comprise baseline testing, i.e., testing the application on the source platform before it is migrated. Testing may also comprise system testing, i.e., testing the application after migration. A set of criteria may be established for verifying proper performance of the application. Both the baseline testing results and the system testing results are compared with the criteria, such that proper performance of the application can be verified both before and after the migration of the application between platforms.

[0066] Testing attributes may comprise any inventory and criteria that might impact upon the length of time or cost for baseline or system testing. Such information may include, for example, the need to create testing programs; whether baseline or system testing requires visits to other sites; the need to setup the application or the testing programs prior to baseline testing; any need to rebuild the application in a clean environment prior to testing; the testing process itself; verifying test results and comparing them to criteria; and debugging of the application after migration. Testing attributes may also comprise the types of testing to be performed, such as unit tests (subroutine level) and whether unit testing will be performed as the application is ported to the new platform; functional tests (tests of user functions) testing of batch processes; integration tests (program level tests of the application's external interfaces); regression tests (movement of data between user functions); performance tests; system management tests (start-up, shutdown, etc.); and hardware tests.

[0067] In accordance with step 307, cost and/or time factors corresponding to each migration attribute received in step 306, and corresponding to the base variables, are assigned to each migration task. For a Type C assessment, the assignment of cost factors is preferably achieved by a user choosing attributes from pre-defined lists. The attributes are then compared with at least one cost factor matrix in a database. Each cost factor matrix contains cost factors for various migration tasks, when at least one attribute is relevant to migrating a specified application from a specified source platform to a specified target platform. Each cost factor matrix may set forth factors for migration tasks, with respect to specific applications. Alternatively, each cost factor matrix may set forth cost factors for migration tasks, with respect to the degree of commonality of various applications. For example, cost factor matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the cost of at least one migration task. Various cost factor matrices are described in further detail, below.

[0068] One example of a cost factor matrix contemplated for returning a Type C assessment is a complexity cost factor matrix. Each complexity cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed by the complexity of migrating an application between a source platform and a target platform. A complexity cost factor matrix may conform substantially to that shown in FIG. 4B, wherein a complexity cost factor, iλS-T, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a source-target combination, ‘S-T’. Note that a complexity cost factor matrix may contain complexity cost factors for more migration tasks than are received in step 303.

[0069] The factors may comprise proportions by which the base costs of migration tasks may be multiplied to reflect the effect of the source-target combination in increasing, decreasing or not affecting, the average base cost of migration tasks during a migration process. The effect of various source-target combinations upon the base cost of each migration task, and hence the development of each complexity cost factor, iλS-T, will be readily appreciated by those skilled in the art.

[0070] A single universal complexity cost factor matrix may be used, or many complexity cost factor matrices may be used, each one containing factors for only one type of source-target combination, such as UNIX-UNIX; Generic UNIX-UNIX Variant; AIXv(x)-AIXv(x+1); Windows XP-Solaris/Intel; and the like. Species of source and target platforms may be particularized (such as Bull OCOS, DG DG-UX, FreeBSD, HP HP-UX, HP MPE, HP NSK, HP OpenVMS/Alpha, HP OpenVMS/VAX, HP Tru64 UNIX, HP VMS/VAX, IBM AIX, IBM DOS/VSE, IBM DYNIX/ptx, IBM MVS, IBM OS/390, IBM zOS, Intel Linux, SCO UnixWare, SGI Irix, Solaris/Intel, Solaris/SPARC, Windows 9x, Windows NT/200, Windows XP and the like). Species of source and target platforms may be non-particularized (such as common platform, uncommon platform, custom platform, proprietary platform, and the like). Particularized and non-particularized species may be combined on a single complexity cost factor matrix and in individual source-target combinations (such as WinXP-proprietary platform).

[0071] Once at least one complexity cost factor matrix is identified that reflects the source-target combination received in step 301, a complexity cost factor, iλS-T, for each migration task, ‘i’, in the assessment template is obtained from the complexity cost factor matrix or matrices. Note that iλS-T may differ for each migration task.

[0072] Another type of cost factor matrix that may be used in returning a Type C assessment is a hardware cost factor matrix. Each hardware cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to the presence of at least one hardware attribute during migration. A hardware cost factor matrix may conform substantially to that shown in FIG. 5, wherein a hardware cost factor, ihk, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a hardware attribute combination, ‘k’. Note that a hardware cost factor matrix may contain hardware cost factors for more migration tasks than are received in step 303.

[0073] The factors may comprise proportions by which the base costs of migration tasks may be multiplied to reflect the effect of at least one hardware attribute in increasing, decreasing or not affecting, the average base costs of the migration tasks during a migration process. The effect of various hardware attribute combinations upon the base cost of each migration task, and hence the development of each hardware cost factor, ihk, will be readily appreciated by those skilled in the art.

[0074] A single universal hardware cost factor matrix may be used, or many hardware cost factor matrices may be used, each one containing factors for only one type of hardware attribute combination, such as external interface combinations, media combinations, byte storage sequencing combinations, and the like. Species of hardware attributes may be particularized (such as big endian to little endian, and the like). Species of hardware attributes may be non-particularized (such as, standard connectivity to non-standard connectivity, common processors to custom processors, and the like). Particularized and non-particularized species may be combined on a single hardware cost factor matrix.

[0075] Once at least one hardware cost factor matrix is identified containing the hardware attribute combinations, 1 . . . k, which were received in accordance with step 306, the hardware cost factors, ih1 . . . ihk, for each migration task in the assessment template are obtained from the hardware cost factor matrix or matrices. Note that ih1 . . . ihk may differ for each migration task.

[0076] Another type of cost factor matrix that may be used in returning a Type C assessment is an operating system (OS) cost factor matrix. Each OS cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to the operating system operated on the source platform (due to, for example, threads, embedded SQL/RDBMS access, kernel mode routines, clustering functionality, operating system intrinsics, library functions, etc.). An OS cost factor matrix may conform substantially to that shown in FIG. 6, wherein an OS cost factor, iωm, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an operating system, ‘m’. Note that an OS cost factor matrix may contain OS cost factors for more migration tasks than are received in step 303.

[0077] The factors may comprise proportions by which the base costs of migration tasks may be multiplied to reflect the effect of the OS operated on the source platform in increasing, decreasing or not affecting, the average base costs of the migration tasks during a migration process. The effect of various operating systems upon the base cost of each migration task, and hence the development of each OS cost factor, iωm, will be readily appreciated by those skilled in the art.

[0078] A single universal OS cost factor matrix may be used, or many OS cost factor matrices may be used, each one containing factors for only one type of operating system. Species of operating systems may be particularized (such as Microsoft Windows® NT, Sun Solaris® and the like). Species of operating systems may be non-particularized (such as, standard, non-standard, custom, and the like). Particularized and non-particularized species may be combined on a single OS cost factor matrix.

[0079] Once at least one OS cost factor matrix is identified containing the operating systems, 1 . . . m, which were received in accordance with step 306, the OS cost factors, iω1 . . . iωm, for each migration task in the assessment template are obtained from the OS cost factor matrix or matrices. Note that iω1 . . . iωm, may differ for each migration task.

[0080] Another type of cost factor matrix that may be used in returning a Type C assessment is an application cost factor matrix. Each application cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to at least one attribute of the application being migrated. An application cost factor matrix may conform substantially to that shown in FIG. 7, wherein an application cost factor, iαn, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an application attribute, ‘n’. Note that an application cost factor matrix may contain application cost factors for more migration tasks than are received in step 303.

[0081] The factors may comprise proportions by which the base costs of migration tasks may be multiplied to reflect the effect of application attributes in increasing, decreasing, or not affecting, the average base costs of the migration tasks during a migration process. The effect of each application attribute upon the base cost of each migration task, and hence the development of each application cost factor, iαn, will be readily appreciated by those skilled in the art.

[0082] A single universal application cost factor matrix may be used, or many application cost factor matrices may be used, each one for a single application attribute, such as real-time operation, OLTP, and the like. Species of applications may be non-particularized (such as, standard, non-standard, custom, and the like). Particularized and non-particularized species may be combined on a single application cost factor matrix.

[0083] Once at least one application cost factor matrix is identified containing the application attributes, 1 . . . n, which were received in accordance with step 306, the application cost factors, iα1 . . . iαn, for each migration task in the assessment template are obtained from the application cost factor matrix or matrices. Note that iα1 . . . iαn, may differ for each migration task.

[0084] Another type of cost factor matrix that may be used in returning a Type C assessment is an environment cost factor matrix. Each environment cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to at least one environment attribute. An environment cost factor matrix may conform substantially to that shown in FIG. 8, wherein an environment cost factor, iεp, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an environment attribute, ‘p’. Note that an environment cost factor matrix may contain environment cost factors for more migration tasks than are received in step 303.

[0085] The factors may comprise proportions by which the base costs of migration tasks may be multiplied to reflect the effect of environment attributes in increasing, decreasing, or not affecting, the average base costs of the migration tasks during a migration process. The effect of each environment attribute upon the base cost of each migration task, and hence the development of each environment cost factor, iεp, will be readily appreciated by those skilled in the art.

[0086] A single universal environment cost factor matrix may be used, or many environment cost factor matrices may be used, each one containing factors for only one type of environment attribute, such as external interface, media, and the like. Species of environment attributes may be particularized (such as 128-bit SSL security, hypertext transfer protocol usage, COBOL language and the like). Species of environment attributes may be non-particularized (such as, standard languages, non-standard security, custom communication transfer protocols, and the like). Particularized and non-particularized species may be combined on a single environment cost factor matrix.

[0087] Once at least one environment cost factor matrix is identified containing the environment attributes, 1 . . . p, which were received in accordance with step 306, the environment cost factors, iε1 . . . iεp, for each migration task in the assessment template are obtained from the environment cost factor matrix or matrices. Note that iε1 . . . iεp, may differ for each migration task.

[0088] Another type of cost factor matrix that may be used in returning a Type C assessment is a testing cost factor matrix. Each testing cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to at least one testing attribute. A testing cost factor matrix may conform substantially to that shown in FIG. 18, wherein a testing cost factor, iηr, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an environment attribute, ‘r’. Note that the effects of testing attributes may only affect, for example, the baseline testing and system testing costs. This example is shown in FIG. 18, where i=2 or 4, because these are the task numbers given to baseline and system testing in the example assessment template shown in FIG. 2.

[0089] The factors may comprise proportions by which the base cost of baseline test and/or system test may be multiplied to reflect the effect of the testing attribute in increasing, decreasing, or not affecting, the average base cost of the baseline testing and/or system testing during a migration process. The effect of each testing attribute upon the base cost of baseline testing and system testing, and hence the development of each environment cost factor, iηr, will be readily appreciated by those skilled in the art.

[0090] A single universal testing cost factor matrix may be used, or many environment cost factor matrices may be used, each one containing factors for only one type of testing attribute, such as re-building the application, use of unit testing, creation of testing programs, testing sites, testing criteria and the like. Species of testing attributes may be particularized (such as no re-building, progressive unit testing, perform baseline test off-site and the like). Species of testing attributes may be non-particularized (such as, standard testing suites, non-standard performance criteria, custom hardware simulation during testing, and the like). Particularized and non-particularized species may be combined on a single testing cost factor matrix.

[0091] Once at least one testing cost factor matrix is identified containing the testing attributes, 1 . . . r, which were received in accordance with step 306, the testing cost factors, iη1 . . . iηr, for baseline and system testing are obtained from the testing cost factor matrix or matrices. Note that iη1 . . . iηr, may differ for each type of testing.

[0092] In accordance with step 308, the cost for the migration is estimated. The calculation of estimated cost is achieved by applying the cost factors assigned in step 307 to the base costs assigned in step 305. The cost ƒ(ci) for each individual migration task received in step 303, other than baseline test and system test, is estimated as follows:

ƒ(ci)=iβiλS-T(i&Hslashed;1i&Hslashed;2 . . . i&Hslashed;n)(iω1iω2 . . . iωm)(iα1iα2 . . . iαn)(iε1iε2 . . . iεp)

[0093] The cost ƒ(c2) for baseline test is estimated as follows:

ƒ(c2)=2β2λS-T(2&Hslashed;12&Hslashed;2 . . . 2&Hslashed;n)(2ω12ω2 . . . 2ωm)(2α12α2 . . . 2αn)(2ε1ε2 . . . 2εp)(2η12η2 . . . 2ηr).

[0094] The cost ƒ(c2) for system test is estimated as follows:

ƒ(c4)=4β4λS-T(4&Hslashed;14&Hslashed;2 . . . 4&Hslashed;n)(4ω14ω2 . . . 4ωm)(4α14α2 . . . 4αn)(4ε14ε2 . . . 4εp)(4η14η2 . . . 4ηr).

[0095] The cost estimate for the migration process shown on the assessment template is then estimated as follows: 1$\sum _{i=1}^{i}f\left(c_i\right)$

[0096] Where time requirements are estimated, step 307 includes assignment of time factors to each migration task. For a Type C assessment, the assignment of time factors is preferably achieved by a user choosing attributes from pre-defined lists. The attributes are then compared with at least one time factor matrix in a database. Each time factor matrix contains time factors for various migration tasks, when at least one attribute is relevant to migrating a specified application from a specified source platform to a specified target platform. Each time factor matrix may set forth factors for migration tasks, with respect to specific applications. Alternatively, each time factor matrix may set forth time factors for migration tasks, with respect to the degree of commonality of various applications. For example, time factor matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the time requirement for at least one migration task.

[0097] Various time factor matrices are described in further detail, below.

[0098] One example of a time factor matrix contemplated for returning a Type C assessment is a complexity time factor matrix. Each complexity time factor matrix sets forth factors, comprising the amounts by which the time requirements for various migration tasks are changed by the complexity of migrating an application between a source platform and a target platform. A complexity time factor matrix may conform substantially to that shown in FIG. 9B, wherein a complexity time factor, iVS-T, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a source-target combination, ‘S-T’. Note that a complexity time factor matrix may contain complexity cost factors for more migration tasks than are received in step 303.

[0099] The complexity time factors may comprise proportions by which the base time requirements for migration tasks may be multiplied to reflect the effect of the source-target combination in increasing, decreasing, or not affecting, the average base time requirement for the migration tasks during a migration process. The effect of each source-target combination upon the base time requirement for each migration task, and hence the development of each complexity time factor, iψS-T, will be readily appreciated by those skilled in the art.

[0100] A single universal complexity time factor matrix may be used, or many complexity time factor matrices may be used, each one containing factors for only one type of source-target combination, such as UNIX-UNIX; Generic UNIX-UNIX Variant; AIXv(x)-AIXv(x+1); Windows XP-Solaris/Intel; and the like. Species of source and target platforms may be particularized (such as Bull GCOS, DG DG-UX, FreeBSD, HP HP-UX, HP MPE, HP NSK, HP OpenVMS/Alpha, HP OpenVMS/VAX, HP Tru64 UNIX, HP VMS/VAX, IBM AIX, IBM DOS/VSE, IBM DYNIX/ptx, IBM MVS, IBM OS/390, IBM zOS, Intel Linux, SCO UnixWare, SGI Irix, Solaris/Intel, Solaris/SPARC, Windows 9x, Windows NT/200, Windows XP and the like). Species of source and target platforms may be non-particularized (such as common platform, uncommon platform, custom platform, proprietary platform, and the like). Particularized and non-particularized species may be combined on a single complexity time factor matrix and in individual source-target combinations (such as WinXP-proprietary platform).

[0101] Once at least one complexity time factor matrix is identified that reflects the source-target combination received in step 301, complexity time factor, iψS-T, for each migration task in the assessment template is obtained from the complexity time factor matrix or matrices. Note that iψS-T may differ for each migration task.

[0102] Another type of time factor matrix that may be used in returning a Type C assessment is a hardware time factor matrix. Each hardware time factor matrix sets forth factors, comprising the amounts by which the time requirements for various migration tasks are changed due to the presence of at least one hardware attribute during migration. A hardware time factor matrix may conform substantially to that shown in FIG. 10, wherein a hardware time factor, iHk, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a hardware attribute combination, ‘k’. Note that a hardware time factor matrix may contain hardware time factors for more migration tasks than are received in step 303.

[0103] The hardware time factors may comprise proportions by which the base time requirements for migration tasks may be multiplied to reflect the effect of the difference in the hardware attributes of the source and target platforms, in increasing, decreasing, or not affecting, the average base time requirement of the migration tasks during a migration process. The effect of each hardware attribute combination upon the base time requirement for each migration task, and hence the development of each hardware time factor, iHk, will be readily appreciated by those skilled in the art.

[0104] A single universal hardware time factor matrix may be used, or many hardware time factor matrices may be used, each one containing factors for only one type of hardware attribute combination, such as external interface combinations, media combinations, byte storage sequencing combinations, and the like. Species of hardware attributes may be particularized (such as big endian to little endian, and the like). Species of hardware attributes may be non-particularized (such as, standard connectivity to non-standard connectivity, common processors to custom processors, and the like). Particularized and non-particularized species may be combined on a single hardware time factor matrix.

[0105] Once at least one hardware time factor matrix is identified containing the hardware attribute combinations, 1 . . . k, which were received in accordance with step 306, the hardware time factors, iH1 . . . iHk, for each migration task in the assessment template are obtained from the hardware time factor matrix or matrices. Note that iH1 . . . iHk, may differ for each migration task.

[0106] Another type of time factor matrix that may be used in returning a Type C assessment is an operating system (OS) time factor matrix. Each OS time factor matrix sets forth factors, comprising the amounts by which the time requirements for various migration tasks are changed due to the operating system operated on the source platform (due to, for example, threads, embedded SQL/RDBMS access, kernel mode routines, clustering functionality, operating system intrinsics, library functions, etc.). An OS time factor matrix may conform substantially to that shown in FIG. 11, wherein an OS time factor, iθm, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an operating system, ‘m’. Note that an OS time factor matrix may contain OS time factors for more migration tasks than are received in step 303.

[0107] The OS time factors may comprise proportions by which the base time requirements for migration tasks may be multiplied to reflect the effect of the dependence of the application upon the initial operating system(s) (due to, for example, threads, embedded SQL/RDBMS access, kernel mode routines, clustering functionality, operating system intrinsics, library functions, etc.) in increasing, decreasing, or not affecting, the average base time requirements for the migration task during a migration process. The effect of each operating system upon the base time requirement for each migration task, and hence the development of each OS time factor, iθm, will be readily appreciated by those skilled in the art.

[0108] A single universal OS time factor matrix may be used, or many OS time factor matrices may be used, each one containing factors for only one type of operating system. Species of operating systems may be particularized (such as Microsoft Windows® NT, Sun Solaris® and the like). Species of operating systems may be non-particularized (such as, standard, non-standard, custom, and the like). Particularized and non-particularized species may be combined on a single OS time factor matrix.

[0109] Once at least one OS time factor matrix is identified containing the operating systems, 1 . . . m, which were received in accordance with step 306, the OS time factors, iθ1 . . . iθm, for each migration task in the assessment template are obtained from the OS time factor matrix or matrices. Note that iθ1 . . . iθm, may differ for each migration task.

[0110] Another type of time factor matrix that may be used in returning a Type C assessment is an application time factor matrix. Each application time factor matrix sets forth factors, comprising the amounts by which the time requirements for various migration tasks are changed due to at least one attribute of the application being migrated. An application time factor matrix may conform substantially to that shown in FIG. 12, wherein an application time factor, in, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an application attribute, ‘n’. Note that an application time factor matrix may contain application time factors for more migration tasks than are received in step 303.

[0111] The application time factors may comprise proportions by which the base times of migration tasks may be multiplied to reflect the effect of application attributes in increasing, decreasing, or not affecting, the average base times of the migration tasks during a migration process. The effect of each application attribute upon the base time requirement for each migration task, and hence the development of each application time factor, in, will be readily appreciated by those skilled in the art.

[0112] A single universal application time factor matrix may be used, or many application time factor matrices may be used, each one for a single application attribute, such as real-time operation, OLTP, and the like. Species of applications may be non-particularized (such as, standard, non-standard, custom, and the like). Particularized and non-particularized species may be combined on a single application time factor matrix.

[0113] Once at least one application time factor matrix is identified containing the application attributes, 1 . . . n, which were received in accordance with step 306, the application time factors, i1 . . . in, for each migration task in the assessment template are obtained from the application time factor matrix or matrices. Note that i1 . . . in may differ for each migration task.

[0114] Another type of time factor matrix that may be used in returning a Type C assessment is an environment time factor matrix. Each environment time factor matrix sets forth factors, comprising the amounts by which the time requirements for various migration tasks are changed due to at least one environment attribute. An environment time factor matrix may conform substantially to that shown in FIG. 13, wherein a environment time factor, iχp, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing an environment attribute, ‘p’. Note that an environment time factor matrix may contain environment time factors for more migration tasks than are received in step 303.

[0115] The factors may comprise proportions by which the base times of migration tasks may be multiplied to reflect the effect of environment attributes in increasing, decreasing, or not affecting, the average base times of the migration tasks during a migration process. The effect of each environment attribute upon the base time requirement for each migration task, and hence the development of each environment time factor, iχp, will be readily appreciated by those skilled in the art.

[0116] A single universal environment time factor matrix may be used, or many environment time factor matrices may be used, each one containing factors for only one type of environment attribute, such as external interface, media, and the like. Species of environment attributes may be particularized (such as 128-bit SSL security, hypertext transfer protocol usage, COBOL language and the like). Species of environment attributes may be non-particularized (such as, standard languages, non-standard security, custom communication transfer protocols, and the like). Particularized and non-particularized species may be combined on a single environment time factor matrix.

[0117] Once at least one environment time factor matrix is identified containing the environment attributes, 1 . . . p, which were received in accordance with step 306, the environment time factors, iχ1 . . . iχp, for each migration task in the assessment template are obtained from the environment time factor matrix or matrices. Note that iχ1 . . . iχp, may differ for each migration task.

[0118] Another type of time factor matrix that may be used in returning a Type C assessment is a testing time factor matrix. Each testing time factor matrix sets forth factors, comprising the amounts by which the times of various migration tasks are changed due to at least one testing attribute. A testing time factor matrix may conform substantially to that shown in FIG. 19, wherein a testing time factor, ir, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a testing attribute, ‘r’. This example is shown in FIG. 19, where i=2 or 4, because these are the task numbers given to baseline and system testing in the example assessment template shown in FIG. 2.

[0119] The factors may comprise proportions by which the base time of baseline test and/or system test may be multiplied to reflect the effect of the testing attribute in increasing, decreasing, or not affecting, the average base time of the baseline testing and/or system testing during a migration process. The effect of each testing attribute upon the base time requirement for baseline testing and system testing, and hence the development of each testing time factor, ir, will be readily appreciated by those skilled in the art.

[0120] A single universal testing time factor matrix may be used, or many testing time factor matrices may be used, each one containing factors for only one type of testing attribute, such as re-building the application, use of unit testing, creation of testing programs, testing sites, testing criteria and the like. Species of testing attributes may be particularized (such as no re-building, progressive unit testing, perform baseline test off-site and the like). Species of testing attributes may be non-particularized (such as, standard testing suites, non-standard performance criteria, custom hardware simulation during testing, and the like). Particularized and non-particularized species may be combined on a single testing time factor matrix.

[0121] Once at least one testing time factor matrix is identified containing the testing attributes, 1 . . . r, which were received in accordance with step 306, the testing time factors, i1 . . . ir, for baseline and system testing are obtained from the testing time factor matrix or matrices. Note that i1 . . . ir, may differ for each type of testing.

[0122] The time requirement for the migration is estimated, in accordance with step 309. The time requirement ƒ(ti) for each individual migration task shown on the assessment template, other than baseline test and system test, is then estimated as follows:

ƒ(ti)=iTiψS-T(iH1iH2 . . . iHk)(iθ1iθ2 . . . iθm)(i1i2 . . . in)(iχ1iχ2 . . . iχp)

[0123] The time requirement for baseline test is estimated as follows:

ƒ(t2)=2T2ψS-T(2H12H2 . . . 2Hk)(2θ12θ2 . . . 2θm)(2122 . . . 2n)(2χ12χ2 . . . 2χp)(21 . . . 2r)

[0124] The time requirement for system test is estimated as follows:

ƒ(t4)=4T4ψS-T(4H14H2 . . . 4Hk)(4θ14θ2 . . . 4θm)(4142 . . . 4n)(4χ14χ2 . . . 4χp)(41 . . . 4r)

[0125] The time estimate for the migration process shown on the assessment template is estimated as follows: 2$\sum _{i=1}^{i}f\left(t_i\right)$

[0126] In accordance with step 310, desired tolerances may be applied in the manner described with reference to FIG. 1. In accordance with step 311, a Type C assessment is output (printed or displayed), which shows estimated costs and/or time requirements for the migration process and each migration task in the assessment template, given the base variables and attributes received. Any such estimates may be represented as fixed numbers or ranges. In the preferred embodiment of the invention, costs and/or time requirements estimated in a Type C assessment are output as ranges.

[0127] FIG. 14 is a flow diagram illustrating a method for returning a Type B assessment for the migration of an application from a source platform to a target platform, in accordance with the current invention. In accordance with step 1401, base variables are received, which comprise an application to be migrated, a source platform on which the application currently operates, and a target platform on which the application is to be re-hosted.

[0128] The application variable may comprise a specific application name and version. Alternatively, the application may include the function of the application and (if more than one function) its component parts, such as production control, batch processing, data mining, online transaction processing (OLTP), or other functions. In the preferred embodiment of the invention, the application variable comprises the name, version and function(s) of the application and its component parts.

[0129] The source and target platform variables may comprise any platforms suitable for operating the application that is to be migrated. These platforms may include, for example, UNIX (generic or variants), OpenVMS, IBM AS/400 or iSeries, HP 300 MPE, IBM Mainframe, and other platforms that are readily known to those skilled in the art.

[0130] In accordance with step 1402, a user's choice of a Type B assessment is received. In accordance with step 1403, an identifier for at least one migration task is received, as described with reference to FIG. 1. In accordance with step 1404, an assessment template may be created in the manner described with reference to FIG. 1. The assessment template for a Type B assessment preferably comprises a representation of migration tasks, which is not as high-level as a Type C assessment template but not as detailed as a Type A assessment template.

[0131] In accordance with step 1405, base costs and/or times are assigned to each migration task. For a Type B assessment, the base variables are preferably compared with at least one base cost matrix in a database. Each base cost matrix sets forth an average base cost for migration tasks, such as those listed previously. A base cost matrix may conform substantially to that shown in FIG. 4A, wherein migration tasks are listed in one column, and a base cost is shown in the row containing a migration task to which the base cost corresponds. A base cost, iβ, is extracted from the database, for each migration task, ‘i’, received in step 1403. Note that each base cost matrix may contain base cost data for more migration tasks than are received in step 1403.

[0132] Each base cost matrix may set forth average costs for migration tasks, with respect to specific applications. Alternatively, each base cost matrix may set forth average base costs for migration tasks, with respect to the degree of commonality of various applications. For example, base cost matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the cost of at least one migration task.

[0133] Where time requirements are being estimated, base time requirements are assigned to each migration task. For a Type B assessment, the base variables are preferably compared with at least one base time matrix in a database. Each base cost matrix sets forth an average base cost for migration tasks, such as those listed previously. A base time requirement matrix may conform substantially to that shown in FIG. 9A, wherein migration tasks are listed in one column, and a base time requirement is shown in the row containing a migration task to which the base time requirement corresponds. A base time, iT, is extracted from the database, for each migration task, ‘i’, received in step 1403. Note that each base cost matrix may contain base time data for more migration tasks than are received in step 1403.

[0134] Each base time requirement matrix may set forth average time requirements for migration tasks, with respect to specific applications. Alternatively, each base time matrix may set forth average base time requirements for migration tasks, with respect to the degree of commonality of various applications. For example, base time matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the time requirement for at least one migration task.

[0135] In accordance with step 1406, at least one additional attribute is received. The migration attributes may comprise, for example, hardware attributes, current operating system attributes, attributes of the application to be migrated, environment attributes, or testing attributes, as these are described with reference to FIG. 3, above.

[0136] In addition to the attributes described above, code metrics are also received, in accordance with 1407. Code metrics may comprise those attributes of the source code of the application being migrated, as those are described with reference to FIG. 1, above. Code metrics are separated into two categories: qualitative and numeric. Qualitative code metrics include such parameters as structural integrity of the application, whether lexical functions are used, the degree to which the application is dependent upon its current operating system, and other code metrics that are not intended to express an actual quantity (even though degrees of a qualitative code metric may be identified by representative numbers). Numeric code metrics include such parameters as code line inventories, code module inventories, file inventories, call and call type inventories, data volume, and other measurable quantities of source code attributes. Code metrics are described further with reference to assignment of factors in step 1408, below.

[0137] Code metrics may be received directly from a user. Alternatively, the source code may be received and analyzed using a suitable utility program for analyzing application source code and returning metrics such as those described herein. The source code may be received via remote electronic transmission to a computing device—via ftp or e-mail, for example—or physical delivery of computer-readable media followed by entry onto a computer system. In one embodiment, the source code is delivered on computer-readable media and then disposed onto a server computer, desktop computer, laptop computer, or other computing device suitable for assessing the source code. In another embodiment, the code may be transmitted via e-mail or ftp to an assessment server or other computing device suitable for analyzing the source code.

[0138] The metric utility may comprise any computer-implemented utility suitable for analyzing application source code and returning code metrics, such as line counts, per type of code; keyword inventories, whether by individual keyword or categories of keywords, such as procedural keywords, data keywords, environment keywords, identification keywords and the like; inventories of files and directory types, such as source code files, copybook files, COM files and the like; or lexical functions; structural integrity; data volume; operating system dependencies; calls and call types to keywords or lexical functions; and other measurable properties of source code that may impact upon the time and cost for migrating an application from a source platform to a target platform.

[0139] In accordance with step 1408, cost and/or time factors corresponding to each attribute received in step 1406, and corresponding to the base variables, are assigned to each migration task received in step 1403. For a Type B assessment, cost factors corresponding to complexity, operating system attributes, hardware attributes, application attributes, environment attributes, and testing attributes, are assigned using matrices, in the manners described with reference to FIG. 3.

[0140] Additionally, cost factors corresponding to code metrics received in step 1407 are also assigned to the migration tasks received in step 1403. Qualitative code metrics obtained are compared with at least one code cost factor matrix. Each code cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to the presence of at least one qualitative attribute in the source code of the application to be re-hosted. A code cost factor matrix may conform substantially to that shown in FIG. 15, wherein a qualitative code cost factor iκq is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a qualitative code metric, ‘q’. Note that a code cost factor matrix may contain code cost factors for more migration tasks than are received in step 1403.

[0141] The qualitative code cost factors may comprise proportions by which the base cost of migration tasks may be multiplied to reflect the effect of the qualitative code metric in increasing, decreasing, or not affecting, the average base cost for the migration tasks during the migration process. The effect of each qualitative code metric upon the average base cost for each migration task, and hence the development of each qualitative code cost factor, iκq, will be readily appreciated by those skilled in the art.

[0142] A single universal code cost factor matrix may be used, or many code cost factor matrices may be used, each one containing only one type of qualitative code metric. Qualitative code metrics may be expressed in dual form (such as, structural integrity=YES; operating system dependent=NO; lexical functions=YES). Alternatively, qualitative code metrics may be categorized by degree (such as, low structural integrity; negligible dependence upon operating system; high use of lexical functions). Dual and categorized qualitative code metric representations may be combined on a single code cost factor matrix.

[0143] Once at least one code cost factor matrix is identified containing the qualitative code metrics, 1 . . . q, which were received in accordance with step 1407, the qualitative code cost factors, iκ1 . . . iκq, for each migration task in the assessment template are obtained from the code cost factor matrix or matrices. Note that iκ1 . . . iκq may differ for each migration task.

[0144] Because an actual quantity is returned for numeric code metrics, the effect of a numeric code metric, ‘s’, on the cost of a migration task, ‘i’, may be accounted for formulaically. As the value returned for the metric (such as number of code lines) increases or decreases, then a numeric code cost factor, iφs, may simply be calculated by an appropriate function, or a group of functions that differ for each type of numeric code metric, 1 . . . s. The functions used to calculate each numeric code cost factor, iφs, may have linear elements, geometric elements, differential elements, or any combination of the three. Additionally, the functions may reflect benchmarks, wherein a numeric code cost factor remains constant over a range of values for the numeric code metric. The effect of each numeric code metric upon the average base cost for each migration task, and hence the formulae for calculating each numeric code cost factor, iφs, will be readily appreciated by those skilled in the art.

[0145] Once factors for each numeric code metric, 1 . . . s, which were received in accordance with step 1407, are calculated for each migration task ‘i’, then a set of numeric code cost factors, iφ1 . . . iφs, is obtained for each migration task. Note that the numeric code cost factors iφ1 . . . iφs may differ for each migration task.

[0146] In accordance with step 1409, the estimated cost ƒ(ci) for each migration task in the assessment template is calculated. The calculation of estimated cost is achieved by applying the cost factors assigned in step 1408 to the base costs assigned in step 1405. Integrating the factors assigned for the code metrics received in step 1407, with the equations described with reference to FIG. 3, the cost ƒ(ci) for each individual migration task received in step 1403, other than baseline test and system test, is then estimated as follows:

ƒ(ci)=iβiλS-T(i&Hslashed;1i&Hslashed;2 . . . i&Hslashed;n)(iω1iω2 . . . iωm)(iα1iα2 . . . iαn)(iε1iε2 . . . iεp)(iκ1iκ2 . . . iκq)(iφ1iφ2 . . . iφs)

[0147] The cost ƒ(c2) for baseline test is estimated as follows:

ƒ(c2)=2β2λS-T(2&Hslashed;12&Hslashed;2 . . . 2&Hslashed;n)(2ω12ω2 . . . 2ωm)(2α12α2 . . . 2αn)(2ε12ε2 . . . 2εp)(2κ12κ2 . . . 2κq)(2φ12φ2 . . . 2φs)(2η1 . . . 2ηr).

[0148] The cost ƒ(c4) for system test is estimated as follows:

ƒ(c4)=4β4λS-T(4&Hslashed;14&Hslashed;2 . . . 4&Hslashed;n)(4ω14ω2 . . . 4ωm)(4α14α2 . . . 4αn)(4ε14ε2 . . . 4εp)(4κ14κ2 . . . 4κq)(4φ14φ2 . . . 4φs)(2η1 . . . 4ηr).

[0149] The cost estimate for the migration process shown on the assessment template is estimated as follows: 3$\sum _{i=1}^{i}f\left(c_i\right)$

[0150] Where time requirements are estimated, step 1408 includes assignment of time factors to each migration task. For a Type B assessment, time factors corresponding to complexity, operating system attributes, hardware attributes, application attributes, environment attributes, and testing attributes, are assigned using matrices, in the manners described with reference to FIG. 3.

[0151] Additionally, time factors corresponding to code metrics received in step 1407 are also assigned to the migration tasks received in step 1403. Qualitative code metrics are compared with at least one code time factor matrix. Each code time factor matrix sets forth factors, comprising the amounts by which the time requirements of various migration tasks are changed due to the presence of at least one qualitative attribute in the source code of the application to be re-hosted. A code time factor matrix may conform substantially to that shown in FIG. 17, wherein a qualitative code time factor, iμq, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a specie of qualitative code metric, ‘q’. Note that a code time factor matrix may contain code time factors for more migration tasks than are received in step 1403.

[0152] The qualitative code time factors may comprise proportions by which the base time requirements for migration tasks may be multiplied to reflect the effect of the qualitative code metric in increasing, decreasing, or not affecting, the average base time requirement for the migration tasks during the migration process. The effect of each qualitative code metric upon the average base time requirement for each migration task, and hence the development of each qualitative code time factor, iμq, will be readily appreciated by those skilled in the art.

[0153] A single universal code time factor matrix may be used, or many code time factor matrices may be used, each one containing only one type of qualitative code metric. Qualitative code metrics may be expressed in dual form (such as, structural integrity=YES; operating system dependent=NO; lexical functions=YES). Alternatively, species of qualitative code metrics may be categorized by degree (such as, low structural integrity; negligible dependence upon operating system; high use of lexical functions). Dual and categorized qualitative code metric representations may be combined on a single code time factor matrix.

[0154] Once at least one code time factor matrix is identified containing the qualitative code metrics, 1 . . . q, which were returned in accordance with step 1407, the qualitative code time factors, iμ1 . . . iμq, for each migration task in the assessment template are obtained from the code time factor matrix or matrices. Note that iμ1 . . . iμq may differ for each migration task.

[0155] Because an actual quantity is returned for numeric code metrics, the effect of a numeric code metric, ‘s’, on the time requirement for a migration task, ‘i’, may be accounted for formulaically. As the value returned for the metric (such as number of code lines) increases or decreases, then a numeric code time factor, iνs, may simply be calculated by an appropriate function, or a group of functions that differ for each type of numeric code metric, 1 . . . s. The functions used to calculate each numeric code time factor, iνs, may have linear elements, geometric elements, differential elements, or any combination of the three. Additionally, the functions may reflect benchmarks, wherein a numeric code time factor remains constant over a range of values for the numeric code metric. The effect of each numeric code metric upon the average base time requirement for each migration task, and hence the formulae for calculating each numeric code time factor, iνs, will be readily appreciated by those skilled in the art.

[0156] Once factors for each numeric code metric, 1 . . . s, which were returned in accordance with step 1409, are calculated for each migration task ‘i’, then a set of numeric code time factors, iν1 . . . iνs, is obtained for each migration task. Note that iν1 . . . iνs may differ for each migration task.

[0157] In accordance with step 1410, the time requirement for the migration is estimated. The calculation of estimated time is achieved by applying the time factors assigned in step 1408 to the base costs assigned in step 1405. Integrating the time factors assigned for the code metrics received in step 1407, with the equations described with reference to FIG. 3, the time requirement ƒ(ti) for each individual migration task shown on the assessment template, other than baseline test and system test, is estimated as follows:

ƒ(ti)=iTiψS-T(iH1iH2 . . . iHk)(iθ1iθ2 . . . iθm)(i1i2 . . . in)(iχ1iχ2 . . . iχp)(iμ1iμ2 . . . iμq)(iv1iv2 . . . ivs)

[0158] The time requirement for baseline test is estimated as follows:

ƒ(t2)=2T2ψS-T(2H12H2 . . . 2Hk)(2θ12θ2 . . . 2θm)(2122 . . . 2n)(2χ12χ2 . . . 2χp)(2μ12μ2 . . . 2μq)(2v12v2 . . . 2vs)(21 . . . 2r)

[0159] The time requirement for system test is estimated as follows:

ƒ(t4)=4T4ψS-T(4H14H2 . . . 4Hk)(4θ14θ2 . . . 4θm)(4142 . . . 4n)(4χ14χ2 . . . 4χp)(4μ14μ2 . . . 4μq)(4v14v2 . . . 4vs)(41 . . . 4r)

[0160] The time estimate for the migration process shown on the assessment template is estimated as follows: 4$\sum _{i=1}^{i}f\left(t_i\right)$

[0161] In accordance with step 1411, desired tolerances are applied in the manner described with reference to FIG. 1. In accordance with step 1412, a Type B assessment is output (printed or displayed), which shows estimated costs and/or time requirements for the migration process and each migration task in the assessment template, given the base variables, attributes and code metrics received. Any such estimates may be represented as fixed numbers or ranges. In the preferred embodiment of the invention, costs and/or time requirements estimated in a Type B assessment are output as ranges.

[0162] FIG. 16 is a flow diagram illustrating a method for returning a Type A assessment for the migration of an application from a source platform to a target platform, in accordance with the current invention. In accordance with step 1601, base variables are received, which comprise an application to be migrated, a source platform on which the application currently operates, and a target platform on which the application is to be re-hosted.

[0163] The application variable may comprise a specific application name and version. Alternatively, the application may include the function of the application and (if more than one function) its component parts, such as production control, batch processing, data mining, online transaction processing (OLTP), or other functions. In the preferred embodiment of the invention, the application variable comprises the name, version and function(s) of the application and its component parts.

[0164] The source and target platform variables may comprise any platforms suitable for operating the computer-based application to be migrated. These platforms may include, for example, UNIX (generic or variants), OpenVMS, IBM AS/400 or iSeries, HP 300 MPE, IBM Mainframe, and other platforms that are readily known to those skilled in the art.

[0165] In accordance with step 1602, a user's choice of a Type B assessment is received. In accordance with step 1603, an identifier for at least one migration task is received, as described with reference to FIG. 1. In accordance with step 1604, an assessment template may be created in the manner described with reference to FIG. 1. The assessment template should contain both high-level tasks and the low-level tasks associated with each, such that cost and time requirements will be estimated in great detail, when compared to a Type C or Type B assessment.

[0166] In accordance with step 1605, base costs and/or times are assigned to each migration task. For a Type A assessment, the base variables are preferably compared with at least one base cost matrix in a database. Each base cost matrix sets forth an average base cost for migration tasks, such as those listed previously. A base cost matrix may conform substantially to that shown in FIG. 4A, wherein migration tasks are listed in one column, and a base cost is shown in the row containing a migration task to which the base cost corresponds. A base cost, iβ, is extracted from the database, for each migration task, ‘i’, received in step 1603. Note that each base cost matrix may contain base cost data for more migration tasks than are received in step 1603.

[0167] Each base cost matrix may set forth average costs for migration tasks, with respect to specific applications. Alternatively, each base cost matrix may set forth average base costs for migration tasks, with respect to the degree of commonality of various applications. For example, base cost matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the cost of at least one migration task.

[0168] Where time requirements are being estimated, base time requirements are assigned to each migration task. For a Type A assessment, the base variables are preferably compared with at least one base time matrix in a database. Each base cost matrix sets forth an average base cost for migration tasks, such as those listed previously. A base time requirement matrix may conform substantially to that shown in FIG. 9A, wherein migration tasks are listed in one column, and a base time requirement is shown in the row containing a migration task to which the base time requirement corresponds. A base time, iT, is extracted from the database, for each migration task, ‘i’, received in step 1603. Note that each base cost matrix may contain base time data for more migration tasks than are received in step 1603.

[0169] Each base time requirement matrix may set forth average time requirements for migration tasks, with respect to specific applications. Alternatively, each base time matrix may set forth average base time requirements for migration tasks, with respect to the degree of commonality of various applications. For example, base time matrices may be built for standard applications (for example, word processors and data storage), non-standard (such as compilers and communication software), and custom-made applications. Matrices may be built to reflect additional qualitative categories of applications that have a quantifiably distinguishable effect on the time requirement for at least one migration task.

[0170] In accordance with step 1606, at least one migration attribute is received. The migration attributes may comprise, for example, hardware attributes, current operating system attributes, attributes of the application to be migrated, environment attributes, or testing attributes, as these are described with reference to FIG. 3, above. To achieve the level of detail required for a Type A assessment to be distinguishable from a Type B assessment, however, additional attributes may need to be considered.

[0171] For a Type A assessment, additional hardware attributes are received that will enable a more accurate cost analysis and plan. Such additional hardware attributes may include, for example, whether the application operates on multiple systems; user connection types (dial-up, serial, WAN, LAN, etc.); and the existence and currency of hardware architecture documentation.

[0172] For a Type A assessment, additional application attributes are received that will enable a more accurate cost analysis and plan. Such additional application attributes may include, for example, unique porting complexities; and whether previous unsuccessful portings have been attempted. Such additional application attributes may also include the existence and currency of application documentation, such as documentation for system and functional requirements; application architecture diagrams; subsystem top-level diagrams; module hierarchical diagrams; user documentation; Y2K documentation; and programming standards documentation.

[0173] For a Type A assessment, additional environment attributes are received that will enable a more accurate cost analysis and plan. Such additional environment attributes may include, for example, how the application is partitioned (client/server, multi-threaded, one large module, discrete modules executable via CALL or ECTL); embedded SQL or DL/I access; and whether the application is X/Open XA compliant.

[0174] Such additional environment attributes may also include, for example, configuration management tools on the source platform (e.g., Panvalet, Librarian); preferred configuration management tools on the target platform; the last re-building of the application; executable images in the application; and whether the application links with non-standard object libraries.

[0175] Such additional environment attributes may also include operating system dependencies, such as multinational character sets; user-written ISPF panels; inter-process communication; SYSPLEX functionality; MACRO calls; CSP map usage; internal EBCDIC coding dependencies; and other such dependencies.

[0176] Such additional environment attributes may also include data storage and access attributes other than type, size and configuration of databases and tables, such as needs to access archived data after migration; timing constraints for cutover; whether data can be accessed on media other than disks; import/export data from/to outside systems; type and size of native files; whether native language I/O are used to access native data files; and whether the application shares data sets with other systems.

[0177] Such additional environment attributes may also include third party products used to implement or augment any of the environment attributes described herein.

[0178] In accordance with step 1607, the source code of the application to be migrated is received. The source code may be received via remote electronic transmission to a computing device—via ftp or e-mail, for example—or physical delivery of computer-readable media followed by entry onto a computer system. In one embodiment, the source code is delivered on computer-readable media and then disposed onto a server computer, desktop computer, laptop computer, or other computing device suitable for assessing the source code. In another embodiment, the code may be transmitted via e-mail or ftp to an assessment server or other computing device suitable for analyzing the source code.

[0179] In accordance with step 1608, metrics are returned for the source code received in step 1607. This may be accomplished by analyzing the source code using a metric utility. The code metrics to be returned may be defined prior to or after analysis of the source code, and may include qualitative and/or numeric code metrics, such as those described previously. The metric utility may comprise any computer-implemented utility suitable for analyzing application source code and returning code metrics, such as line counts, per type of code; keyword inventories, whether by individual keyword or categories of keywords, such as procedural keywords, data keywords, environment keywords, identification keywords and the like; inventories of files and directory types, such as source code files, copybook files, COM files and the like; or lexical functions; structural integrity; data volume; operating system dependencies; calls and call types to keywords or lexical functions; and other measurable properties of source code that may impact upon the time and cost for migrating an application from a source platform to a target platform.

[0180] In accordance with step 1609, cost and/or time factors corresponding to each attribute received in step 1606, and corresponding to the base variables, are assigned to each migration task received in step 1603. For a Type A assessment, cost factors corresponding to complexity, operating system attributes, hardware attributes, application attributes, environment attributes, and testing attributes, are assigned using matrices, in the manners described with reference to FIG. 3.

[0181] Additionally, cost factors corresponding to code metrics received in step 1608 are also assigned to the migration tasks received in step 1603. Qualitative code metrics obtained are compared with at least one code cost factor matrix. Each code cost factor matrix sets forth factors, comprising the amounts by which the costs of various migration tasks are changed due to the presence of at least one qualitative attribute in the source code of the application to be re-hosted. A code cost factor matrix may conform substantially to that shown in FIG. 15, wherein a qualitative code cost factor iκq is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a qualitative code metric, ‘q’. Note that a code cost factor matrix may contain code cost factors for more migration tasks than are received in step 1603.

[0182] The qualitative code cost factors may comprise proportions by which the base cost of migration tasks may be multiplied to reflect the effect of the qualitative code metric in increasing, decreasing, or not affecting, the average base cost for the migration tasks during the migration process. The effect of each qualitative code metric upon the average base cost for each migration task, and hence the development of each qualitative code cost factor, iκq, will be readily appreciated by those skilled in the art.

[0183] A single universal code cost factor matrix may be used, or many code cost factor matrices may be used, each one containing only one type of qualitative code metric. Qualitative code metrics may be expressed in dual form (such as, structural integrity=YES; operating system dependent=NO; lexical functions=YES). Alternatively, qualitative code metrics may be categorized by degree (such as, low structural integrity; negligible dependence upon operating system; high use of lexical functions). Dual and categorized qualitative code metric representations may be combined on a single code cost factor matrix.

[0184] Once at least one code cost factor matrix is identified containing the qualitative code metrics, 1 . . . q, which were received in accordance with step 1608, the qualitative code cost factors, iκ1 . . . iκq, for each migration task in the assessment template are obtained from the code cost factor matrix or matrices. Note that iκ1 . . . iκq may differ for each migration task.

[0185] Because an actual quantity is returned for numeric code metrics, the effect of a numeric code metric, ‘s’, on the cost of a migration task, ‘i’, may be accounted for formulaically. As the value returned for the metric (such as number of code lines) increases or decreases, then a numeric code cost factor, iφs, may simply be calculated by an appropriate function, or a group of functions that differ for each type of numeric code metric, 1 . . . s. The functions used to calculate each numeric code cost factor, iφs, may have linear elements, geometric elements, differential elements, or any combination of the three. Additionally, the functions may reflect benchmarks, wherein a numeric code cost factor remains constant over a range of values for the numeric code metric. The effect of each numeric code metric upon the average base cost for each migration task, and hence the formulae for calculating each numeric code cost factor, iφs, will be readily appreciated by those skilled in the art.

[0186] Once factors for each numeric code metric, 1 . . . s, which were received in accordance with step 1608, are calculated for each migration task ‘i’, then a set of numeric code cost factors, iφ1 . . . iφs, is obtained for each migration task. Note that the numeric code cost factors iφ1 . . . iφs may differ for each migration task.

[0187] In accordance with step 1610, a plurality of customized cost factors iγ1 . . . iγt are received from a user for at least one migration task, ‘i’, and at least one additional attribute, ‘t’. Customized cost factors may be received from a user, in relation to the attributes described with reference to step 1606, or the code metrics returned in step 1608, in place of any factors obtained using the matrices or calculations described herein. The customized cost factors may also relate to attributes not contained in such matrices, which the user desires to include in cost estimation. The customized cost factors, iγ1 . . . iγt, may be received in list form, or they may be filled in on a matrix template or multiple matrix templates, for storage and later reference.

[0188] Customized cost factors may comprise proportions by which the base cost of migration tasks may be multiplied to reflect the effect of additional attributes in increasing, decreasing, or not affecting, the average base cost of the migration tasks during a migration process. The effect of each additional attribute upon the base cost of each migration task, and hence the development of each customized cost factor, iγt, will be readily appreciated by those skilled in the art. Note that iγ1 . . . iγt may differ for each migration task.

[0189] In accordance with step 1611, the estimated cost ƒ(ci) for each migration task in the assessment template is calculated. The calculation of estimated cost is achieved by applying the cost factors assigned in step 1609 and the custom factors received in 1610 to the base costs assigned in step 1605. Integrating the factors assigned for the code metrics received in step 1609, and the custom cost factors received in step 1610, with the equations described with reference to FIG. 3, the cost ƒ(ci) for each individual migration task received in step 1603, other than baseline test and system test, is estimated as follows:

ƒ(ci)=iβiλS-T(i&Hslashed;1i&Hslashed;2 . . . i&Hslashed;n)(iω1iω2 . . . iωm)(iα1iα2 . . . iαn)(iε1iε2 . . . iεp)(iκ1iκ2 . . . iκq)(iφ1iφ2 . . . iφs)(iγ1iγ2 . . . iγt)ps

[0190] The cost ƒ(c2) for baseline test is estimated as follows:

ƒ(c2)=2β2λS-T(2&Hslashed;12&Hslashed;2 . . . 2&Hslashed;n)(2ω12ω2 . . . 2ωm)(2α12α2 . . . 2αn)(2ε12ε2 . . . 2εp)(2κ12κ2 . . . iκq)(2φ12φ2 . . . 2φs)(2γ12γ2 . . . 2γt)(2η1 . . . 2ηr)

[0191] The cost ƒ(c4) for system test is estimated as follows:

ƒ(c4)=4β4λS-T(4&Hslashed;14&Hslashed;2 . . . 4&Hslashed;n)(4ω14ω2 . . . 4ωm)(4α14α2 . . . 4αn)(4ε14ε2 . . . 4εp)(4κ14κ2 . . . 4κq)(4φ14φ2 . . . 4φs)(4γ14γ2 . . . 4γt)(4η1 . . . 4ηr).

[0192] The cost estimate for the migration process shown on the assessment template is estimated as follows: 5$\sum _{i=1}^{i}f\left(c_i\right)$

[0193] Where time requirements are estimated, step 1609 includes assignment of time factors to each migration task. For a Type A assessment, time factors corresponding to complexity, operating system attributes, hardware attributes, application attributes, environment attributes, and testing attributes, are assigned using matrices, in the manners described with reference to FIG. 3.

[0194] Additionally, time factors corresponding to code metrics returned in step 1608 are also assigned to the migration tasks received in step 1603. Qualitative code metrics are compared with at least one code time factor matrix. Each code time factor matrix sets forth factors, comprising the amounts by which the time requirements of various migration tasks are changed due to the presence of at least one qualitative attribute in the source code of the application to be re-hosted. A code time factor matrix may conform substantially to that shown in FIG. 17, wherein a qualitative code time factor, iμq, is shown at the intersection of each row containing a migration task, ‘i’, and a column containing a specie of qualitative code metric, ‘q’. Note that a code time factor matrix may contain code time factors for more migration tasks than are received in step 1603.

[0195] The qualitative code time factors may comprise proportions by which the base time requirements for migration tasks may be multiplied to reflect the effect of the qualitative code metric in increasing, decreasing, or not affecting, the average base time requirement for the migration tasks during the migration process. The effect of each qualitative code metric upon the average base time requirement for each migration task, and hence the development of each qualitative code time factor, iμq, will be readily appreciated by those skilled in the art.

[0196] A single universal code time factor matrix may be used, or many code time factor matrices may be used, each one containing only one type of qualitative code metric. Qualitative code metrics may be expressed in dual form (such as, structural integrity=YES; operating system dependent=NO; lexical functions=YES). Alternatively, species of qualitative code metrics may be categorized by degree (such as, low structural integrity; negligible dependence upon operating system; high use of lexical functions). Dual and categorized qualitative code metric representations may be combined on a single code time factor matrix.

[0197] Once at least one code time factor matrix is identified containing the qualitative code metrics, 1 . . . q, which were returned in accordance with step 1608, the qualitative code time factors, iμ1 . . . iμq, for each migration task in the assessment template are obtained from the code time factor matrix or matrices. Note that iμ1 . . . iμq may differ for each migration task.

[0198] Because an actual quantity is returned for numeric code metrics, the effect of a numeric code metric, ‘s’, on the time requirement for a migration task, ‘i’, may be accounted for formulaically. As the value returned for the metric (such as number of code lines) increases or decreases, then a numeric code time factor, iνs, may simply be calculated by an appropriate function, or a group of functions that differ for each type of numeric code metric, 1 . . . s. The functions used to calculate each numeric code time factor, iνs, may have linear elements, geometric elements, differential elements, or any combination of the three. Additionally, the functions may reflect benchmarks, wherein a numeric code time factor remains constant over a range of values for the numeric code metric. The effect of each numeric code metric upon the average base time requirement for each migration task, and hence the formulae for calculating each numeric code time factor, iνs, will be readily appreciated by those skilled in the art.

[0199] Once factors for each numeric code metric, 1 . . . s, which were returned in accordance with step 1608, are calculated for each migration task ‘i’, then a set of numeric code time factors, iν1 . . . iνs, is obtained for each migration task. Note that iν1 . . . iνs may differ for each migration task.

[0200] Also, where time requirements are estimated, a plurality of customized time factors, iσ1 . . . iσt, may be received from a user, in accordance with step 1610, for at least one migration task, ‘i’, and at least one additional attribute, ‘t’. Customized time factors may be received from a user, in relation to the attributes described with reference to step 1606, or the code metrics returned in step 1608, in place of any factors obtained using the matrices or calculations described herein. The customized time factors may also relate to attributes not contained in such matrices, which the user desires to include in estimation of time requirements. The customized time factors, iσ1 . . . iσt, may be received in list form, or they may be filled in on a matrix template or multiple matrix templates, for storage and later reference.

[0201] Customized time factors may comprise proportions by which the base time of migration tasks may be multiplied to reflect the effect of the additional attribute in increasing, decreasing, or not affecting, the average base time requirement for the migration tasks during a migration process. The effect of each additional attribute upon the base time requirement for each migration task, and hence the development of each customized time factor, iσt, will be readily appreciated by those skilled in the art. Note that iσ1 . . . iσt may differ for each migration task.

[0202] In accordance with step 1612, the time requirement for the migration is estimated. The calculation of estimated time is achieved by applying the time factors assigned in step 1609 and the custom factors received in step 1610 to the base costs assigned in step 1605. Integrating the time factors assigned for the code metrics returned in step 1608, and the custom time factors received in step 1610, with the equations described with reference to FIG. 3, the time requirement ƒ(ti) for each individual migration task shown on the assessment template, other than baseline test and system test, is estimated as follows:

ƒ(ti)=iTiψS-T(iH1iH2 . . . iHk)(iθ1iθ2 . . . iθm)(i1i2 . . . in)(iχ1iχ2 . . . iχp)(iμ1iμ2 . . . iμq)(iν1iν2 . . . iνs)(iσ1iσ2 . . . iσt)

[0203] The time requirement for baseline test is estimated as follows:

ƒ(t2)=2T2ψS-T(2H12H2 . . . 2Hk)(2θ12θ2 . . . 2θm)(2122 . . . 2n)(2χ12χ2 . . . 2χp)(2μ12μ2 . . . 2μq)(2ν12ν2 . . . 2νs)(2σ12σ2 . . . 2σt)(21 . . . 2r)

[0204] The time requirement for system test is estimated as follows:

ƒ(t4)=4T4ψS-T(4H14H2 . . . 4Hk)(4θ14θ2 . . . 4θm)(4142 . . . 4n)(4χ14χ2 . . . 4χp)(4μ14μ2 . . . 4μq)(4ν14ν2 . . . 4νs)(4σ14σ2 . . . 4σt)(41 . . . 4r)

[0205] The time estimate for the migration process shown on the assessment template is estimated as follows: 6$\sum _{i=1}^{i}f\left(t_i\right)$

[0206] In accordance with step 1613, desired tolerances are applied in the manner described with reference to FIG. 1. In accordance with step 1614, a Type A assessment is output, which shows estimated costs and/or time requirements for the migration process and each migration task in the assessment template, given the base variables, attributes and code metrics received. Any such estimates may be represented as fixed numbers or ranges. In the preferred embodiment of the invention, costs and/or time requirements estimated in a Type A assessment are output as ranges, which are accurate within thirty percent (30%). More preferably, the estimates are accurate within fifteen to twenty-five percent (15-25%).

[0207] The invention is also directed to computer-readable program products having computer-readable program code means for producing cost and time requirement estimates for migration projects, in accordance with the various embodiments of the method described herein. Selecting appropriate media and implementing the process described herein on such media are matters that will be readily known to those skilled in the art.

[0208] While the foregoing material describes and illustrates the current invention with reference to particular embodiments, these embodiments are intended as examples and not to define the entire scope of the current invention. Those skilled in the art will appreciate that many aspects of these embodiments may be changed and steps of the various methods re-arranged, such as creation of template, assignment of base costs and receiving additional data, without departing from the spirit or scope of the invention.

Claims

1. A computer-implemented method for estimating a cost for migrating a computer-based application from a source platform to a target platform, said method comprising the steps of: receiving identifications of respective migration tasks; correlating base costs to respective ones of said migration tasks; receiving identifications of migration attributes that affect migration cost; correlating cost factors to respective ones of said migration tasks, each of said cost factors indicating an amount by which a migration attribute affects the base cost of a migration task; and estimating a cost for each migration task, by applying the cost factors for each migration task to the base cost of the migration task.

2. The method of claim 1, wherein migration tasks comprise one or more tasks chosen from a group consisting of system building, project management, ramp up, baseline testing, migration, system testing, delivery, acceptance testing, sign-off, exporting data, importing data, redirecting user terminals, replacing third party products, and deployment.

3. The method of claim 1, wherein migration attributes comprise one or more attributes chosen from a group consisting of hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, complexity attributes, and testing attributes.

4. The method of claim 3, wherein source code attributes comprise at least one code metric chosen from a group consisting of number of code lines, number of code modules, number of files, call types, number of calls, data volume, structural integrity, use of lexical functions, and operating system dependence.

5. The method of claim 1, further comprising estimating a total cost, by summing the estimated costs of all migration tasks; and displaying or printing a migration assessment comprising the total cost.

6. The method of claim 5, wherein the migration assessment further comprises the estimated cost for each migration task.

7. The method of claim 5, further comprising applying tolerances to one or more of the estimated costs and total cost; and wherein one or more of the estimated costs and total cost comprises a cost range.

8. The method of claim 1, wherein one or more of the base costs are received from a user.

9. The method of claim 1, wherein one or more of the cost factors are received from a user.

10. The method of claim 1, further comprising the step of receiving at least one assessment type, each assessment type comprising a degree of accuracy for one or more of the estimated costs and total cost.

11. The method of claim 1, further comprising the step of creating an assessment template, the assessment template comprising a format for the migration assessment.

12. The method of claim 1, further comprising the steps of: correlating base time requirements to respective ones of said migration tasks; correlating time factors to respective ones of said migration tasks, each time factor indicating an amount by which a migration attribute changes the base time requirement for a migration task; and estimating a time requirement for each migration task, by applying all time factors for the migration task to the base time requirement for the migration task.

13. A computer-implemented method for estimating a time requirement for migrating a computer-based application from a source platform to a target platform, comprising: receiving identifications for respective migration tasks; correlating base time requirements to respective ones of said migration tasks; receiving identifications of migration attributes that affect migration time; correlating time factors to respective ones of said migration tasks, each time factor indicating an amount by which a migration attribute changes the base time requirement for a migration task; and estimating a time requirement for each migration task, by applying all time factors for the migration task to the base time requirement of the migration task.

14. The method of claim 13, wherein migration tasks comprise one or more tasks chosen from a group consisting of system building, project management, ramp up, baseline testing, migration, system testing, delivery, acceptance testing, sign-off, exporting data, importing data, redirecting user terminals, replacing third party products, and deployment.

15. The method of claim 13, wherein migration attributes comprise one or more attributes chosen from a group consisting of hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, complexity attributes, and testing attributes.

16. The method of claim 15, wherein source code attributes comprise at least one code metric chosen from a group consisting of number of code lines, number of code modules, number of files, call types, number of calls, data volume, structural integrity, use of lexical functions, and operating system dependence.

17. The method of claim 13, further comprising estimating a total time requirement, by summing the time requirements for all migration tasks; and printing or displaying a migration assessment comprising the total time requirement.

18. The method of claim 17, wherein the migration assessment further comprises the estimated time requirement for each migration task.

19. The method of claim 17, further comprising applying tolerances to one or more of the estimated time requirements and total time requirement; and wherein one or more of the estimated time requirements and total time requirement comprises a cost range.

20. The method of claim 13, wherein one or more of the base time requirements are received from a user.

21. The method of claim 13, wherein one or more of the time factors are received from a user.

22. The method of claim 13, further comprising the step of receiving at least one assessment type, each assessment type comprising a degree of accuracy for one or more of the estimated time requirements and total time requirement.

23. The method of claim 13, further comprising the step of creating an assessment template, the assessment template comprising a format for the migration assessment.

24. A computer-readable program product for estimating a cost for migrating a computer-based application from a source platform to a target platform, comprising: computer-readable program code means for receiving identifications of respective migration tasks; computer-readable program code means for correlating base costs to respective ones of said migration tasks; computer-readable program code means for receiving identifications of migration attributes; computer-readable program code means for correlating cost factors to respective ones of said migration tasks, each cost factor indicating an amount by which a migration attribute changes the base cost of a migration task; and computer-readable program code means for estimating a cost for each migration task, by applying all cost factors for the migration task to the base cost of the migration task.

25. The computer-readable program product of claim 24, wherein migration tasks comprise one or more tasks chosen from a group consisting of system building, project management, ramp up, baseline testing, migration, system testing, delivery, acceptance testing, sign-off, exporting data, importing data, redirecting user terminals, replacing third party products, and deployment.

26. The computer-readable program product of claim 24, wherein migration attributes comprise one or more attributes chosen from a group consisting of hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, complexity attributes, and testing attributes.

27. The computer-readable program product of claim 26, wherein source code attributes comprise at least one code metric chosen from a group consisting of number of code lines, number of code modules, number of files, call types, number of calls, data volume, structural integrity, use of lexical functions, and operating system dependence.

28. The computer-readable program product of claim 24, further comprising computer-readable program code means for estimating a total cost, by summing the estimated costs of all migration tasks; and computer-readable program code means for printing or displaying a migration assessment comprising the total cost.

29. The computer-readable program product of claim 28, wherein the migration assessment further comprises the estimated cost for each migration task.

30. The computer-readable program product of claim 28, further comprising computer-readable program code means for applying tolerances to one or more of the estimated costs and total cost; and wherein one or more of the estimated costs and total cost comprises a cost range.

31. The computer-readable program product of claim 24, further comprising computer-readable program code means for receiving one or more of the base costs from a user.

32. The computer-readable program product of claim 24, further comprising computer-readable program code means for receiving one or more of the cost factors from a user.

33. The computer-readable program product of claim 24, further comprising computer-readable program code means for receiving at least one assessment type, each assessment type comprising a degree of accuracy for one or more of the final costs and total cost.

34. The computer-readable program product of claim 24, further comprising computer-readable program code means for creating an assessment template, the assessment template comprising a format for the assessment.

35. The computer-readable program product of claim 24, further comprising: computer-readable program code means for correlating base time requirements to respective ones of said migration tasks; computer-readable program code means for correlating time factors to respective ones of said migration tasks, each time factor indicating an amount by which a migration attribute changes the base time requirement for a migration task; and computer-readable program code means for estimating a time requirement for each migration task, by applying all time factors for the migration task to the base time requirement for the migration task.

36. A computer-readable program product for estimating a time requirement for migrating a computer-based application from a source platform to a target platform, comprising: computer-readable program code means for receiving identifications of respective migration tasks; computer-readable program code means for correlating base time requirements to respective ones of said migration tasks; computer-readable program code means for receiving identifications of respective migration attributes; computer-readable program code means for correlating time factors to respective ones of said migration tasks, each time factor indicating an amount by which a migration attribute changes the base time requirement for a migration task; and computer-readable program code means for estimating a time requirement for each migration task, by applying all time factors for the migration task to the base time requirement of the migration task.

37. The computer-readable program product of claim 36, wherein migration tasks comprise one or more tasks chosen from a group consisting of system building, project management, ramp up, baseline testing, migration, system testing, delivery, acceptance testing, sign-off, exporting data, importing data, redirecting user terminals, replacing third party products, and deployment.

38. The computer-readable program product of claim 36, wherein migration attributes comprise one or more attributes chosen from a group consisting of hardware attributes, operating system attributes, application attributes, environment attributes, source code attributes, complexity attributes, and testing attributes.

39. The computer-readable program product of claim 38, wherein source code attributes comprise at least one code metric chosen from a group consisting of number of code lines, number of code modules, number of files, call types, number of calls, data volume, structural integrity, use of lexical functions, and operating system dependence.

40. The computer-readable program product of claim 36, further comprising computer-readable program code means for estimating a total time requirement, by summing the estimated time requirements for all migration tasks; and computer-readable program code means for printing or displaying a migration assessment comprising the total time requirement.

41. The computer-readable program product of claim 40, wherein the migration assessment further comprises the estimated time requirement for each migration task.

42. The computer-readable program product of claim 40, further comprising computer-readable program code means for applying tolerances to one or more of the estimated time requirements and total time requirement; and wherein one or more of the estimated time requirements and total time requirement comprises a time range.

43. The computer-readable program product of claim 36, further comprising computer-readable program code means for receiving one or more of the base time requirements from a user.

44. The computer-readable program product of claim 36, further comprising computer-readable program code means for receiving one or more of the time factors from a user.

45. The computer-readable program product of claim 36, further comprising computer-readable program code means for receiving at least one assessment type, each assessment type comprising a degree of accuracy for one or more of the final time requirements and total time requirement.

46. The computer-readable program product of claim 36, further comprising computer-readable program code means for creating an assessment template, the assessment template comprising a format for the assessment.