Getting Systems in Line

Data conversions are a given for law firms implementing new systems, switching to new vendor platforms or upgrading existing systems. The number of practice-related system transitions that a typical law firm experiences (e.g., moving from Vendor X's to Vendor Y's software; upgrading from system Version 1 to Version 2) correlates with the adoption strategies and overall technology goals of a firm. Long ago, most mid- to large-sized law firms implemented financial systems specifically designed to efficiently invoice clients in accordance with time and expenses associated with specific representations.

As law firms realized the benefits of having a billing system specifically designed to their needs, they sought out systems that could help streamline the then-manual processes for searching conflicts and managing client files. Financial software vendors responded and established an early and majority market share in implementing conflicts and records management systems. Many firms are on their fourth or fifth iterations of their accounting software, whereas vendor swaps or upgrades related to records management systems and/or conflicts management systems may just now be coming into play. It logically follows that IT personnel are most likely more familiar with the processes involved in managing time and billing system conversions. However, the same methodology cannot be applied universally from system to system. For firms about to embark on records management or conflicts management conversions, recognition of how these key firm systems define and manage data is critical to ensuring a successful transition.

What Makes Records and Conflicts
Data Conversions More Complex?

Accounting and financial systems are used to track client and matter data, billable hours, invoice clients, manage accounts receivable and accounts payable, develop and monitor budgets and measure the firm's financial performance. Virtually all information is centralized and organized according to client/matter number, invoice or batch number. This information is key to the business operations of the firm and can be quite voluminous, but it is very objective and managed consistently (or very similarly) from vendor system to vendor system.

Records and conflicts systems, on the other hand, manage a broad range of data and support operations that are not guided by long-established best practices and are not consistent from firm to firm or even from vendor to vendor. Migration of this data without a loss of information can be very difficult. Any disruption to operations resulting from an inability to access information can result in a breach of ethical responsibilities, loss of client-owned information and a lack of compliance with firm procedures such as retention of client files.

Records management systems may manage data including:

• Client and matter details;
• Physical file location information;
• Folder and box creation and activity data;
• Document-level metadata;
• Scanned and native-format electronic documents;
• Security/access details applied to physical and electronic information;
• Ethical wall information;
• Retention periods and rules for physical and electronic data; and
• Remotely managed content in document management systems, file shares and other firm applications.

Conflicts management systems are used to search for and report potential conflicts of interest and typically manage data including:

• Client and matter details;
• Information on parties involved with matters and the nature of their relationships;
• Lateral hire information that may not have resulted in formal matters;
• Details of conflicts waivers;
• Client engagement and disengagement letters; and
• Search history.

Shared Functions

While records management and conflicts management systems are fundamentally different and offer unique functionality, they both share characteristics that impact conversion planning similarly, including:

• Varying classification schemas. While records and conflicts systems ultimately relate most data to clients and matters, other relationships and hierarchies are often involved. A new system may employ hierarchical folders where none was present previously and make different assumptions about the relationship between storage files and inserts. The ability to profile documents may only be allowed beneath the folder level and not directly under the client or matter. Your firm may have conflicts-related data on involved parties stored as notes on client and matter records where the new system handles these relationships through relational database tables and needs to be parsed out to utilize the system's full capabilities.
• Multiple repositories. Firms undertaking a conversion typically draw in data from a number of sources. Even with an upgrade, the links to data in other repositories may have to be considered. For example, a record may be locked down and classified in the firm's records management system, but the actual record itself may reside in an e-mail archival or document management system.
• Manual and electronic. Even though records and conflicts systems automate these processes, manual steps are usually still employed at some level. There are often disparate spreadsheets and databases in use by pockets of users. Manual logs might hold valuable record delivery information. These sources of data have to be evaluated for their value.
• Risk management. Both systems play a significant role in firm risk management, ensuring compliance and mitigating risks that can lead to malpractice claims, reputation loss and client satisfaction issues. Data cannot be lost during conversion and downtime must be minimal. The firm cannot suspend conflicts searching for a few days or halt delivery of client files during a conversion.

Having a solid understanding of these factors prior to conversion planning will help ensue accuracy and minimize down time.

Planning a Successful Conversion

1. Take the time to meet with the firm personnel that actually use these systems on a daily basis. Understand their primary goals and how they're expecting to benefit from the migration. Consider new functionality as well as fixes for existing tasks. For example, have they been using cumbersome workarounds that can be eliminated via the upgrade? Can existing frustrations be minimized with proper planning? Have there been changes in policy or procedures that impact how they need to use the technology?

Also, be aware of overall strategic firm goals and initiatives that might impact these systems and how they are implemented.

2. With clear insight into the project goals, start by defining the data that is available and what you want managed in the new system. Look at all systems that house data, whether formally supported or not, including manual workarounds (e.g., assistant-created Access databases for offsite storage holdings). Consider how users plan to index and search against this information. A particular piece of metadata that was being tracked might not have a defined field in the database with the new system. Can it be mapped to a comment field? Does it need to be searchable? You must know enough about the front-end functionality of the new system to understand how end users will access and utilize the information being converted.

3. Identify the value of the data and determine what you want to have in the new system. When consolidating data from a number of sources, there may be duplicate information, but there is typically some value that can be drawn from each. For instance, while you might convert data on boxes in storage from a flat database kept by the records department that has the most detail on box content, a report from the offsite storage vendor may be the best source of data on the current status of the box and its recall history. The goal is to centralize all of the information in the new or upgraded system to minimize point of reference.

4. Review all integrations with other firm systems. Often, new client and matter data is brought over from the firm's accounting system or information is created directly from an automated intake process. While conversion will cover existing data, there must be plans in place to seamlessly capture day-forward data. Integrations between records and document management systems are frequently defined and conflicts systems may search other databases like CRM systems. Will this functionality be part of the initial rollout or added later in the process?

5. Calculate as much as possible using hard numbers ' number of boxes, rows in a database table, clients, matters, files, documents, parties, etc. These numbers can be your first point of comparison when evaluating the success of a data conversion. When converting tens or hundreds of thousands of records it can be difficult to manually review a representative percentage of the records.

6. Memorialize all mapping decisions in a mapping document. Documenting logic that needs to be built into conversion scripts can be very important if drawing from multiple sources. You may need to document the order of operation if you are pulling potentially duplicative data from multiple sources. Related party information from one source cannot be brought over until the client and matter records they relate to have been converted from another source in some cases.

7. Once the specifications of the end system are known, identify the sources of information and look at existing formatting versus the planned formatting. Will the amount of data fit in the intended field? Do dates exist in multiple formats? Do values such as state and country information have to match a format dictated by a lookup table to display properly?

8. Meet regularly with conversion technicians and functional users to ensure that expectations match. Define your timeline and the process by which conversion decisions will be documented and approved prior to any work beginning. Define responsibilities for extracting and formatting existing data as well as any cleanup that needs to happen before or after conversion.

Conversion Testing and Validation

Plan for at least one test conversion to allow your team to evaluate conversion decisions and unforeseen inconsistencies in testing results. Plan the timeline for delivering all needed data to the conversion team and when the actual conversion will take place. You may need to coordinate installation of a new application in conjunction with the data conversion. A new system may also require that some or all end users receive training before they can navigate the product and test adequately. There should be a defined time period for data testing and an agreed upon format for documenting and communicating any problems identified. Ideally, a single individual can coordinate all issues found during testing to eliminate duplicate issues and identify those related to user error. Consolidating all testing results will also illuminate common consistent problems like leading zeros that were lost on extraction while the data was stored in a spreadsheet format or sources that were forgotten altogether.

Have a testing plan and spreadsheet document to memorialize the testing and test reconciliation. Testers should be guided in exactly the type and volume of data that should be tested, and must differentiate between product functionality issues and data issues. Ideally, you should target a goal for the percentage of data to review, for example, testing 10% of the data as a valid representation of accuracy. However, with thousands of matters, that's not always viable. Another approach is to identify major representational classes to look at and to divide this work amongst the testing group. One tester may focus on client and matter records while another focuses on folder or party data. If testers have different levels of familiarity, one might be asked to focus on a particular practice area or the records from a single firm office. Users should be asked to document, field by field, that the converted data looks as expected when compared against the source data. Keep this information in a spreadsheet where testers can detail any discrepancies.

On a more technical level, perform table counts and compare the numbers (e.g., box table records, client table records, matter table records). However, it can be difficult to rely on this methodology because information may have been transformed on conversion according to the firm's specifications. Typical manipulations that may throw off data counts include de-duping, parsing or consolidation of data, and varying methods of indexing data.

Work with the conversion team to identify and apply fixes to errors found in the initial test conversion. Determine if you need to amend logic and conversion methodology. Any changes should be logged in the data-mapping document. After the next test conversion (or final conversion) is performed, prioritize testing identified issues, and then re-check a percentage of all data to ensure that fixes implemented to correct identified issues did not create additional errors.

Records management or conflicts management system conversions are not necessarily more difficult than other system upgrades, however they do require a little more up-front planning and attention to ensure a smooth transition and minimal disruption.

Data conversions are a given for law firms implementing new systems, switching to new vendor platforms or upgrading existing systems. The number of practice-related system transitions that a typical law firm experiences (e.g., moving from Vendor X's to Vendor Y's software; upgrading from system Version 1 to Version 2) correlates with the adoption strategies and overall technology goals of a firm. Long ago, most mid- to large-sized law firms implemented financial systems specifically designed to efficiently invoice clients in accordance with time and expenses associated with specific representations.

As law firms realized the benefits of having a billing system specifically designed to their needs, they sought out systems that could help streamline the then-manual processes for searching conflicts and managing client files. Financial software vendors responded and established an early and majority market share in implementing conflicts and records management systems. Many firms are on their fourth or fifth iterations of their accounting software, whereas vendor swaps or upgrades related to records management systems and/or conflicts management systems may just now be coming into play. It logically follows that IT personnel are most likely more familiar with the processes involved in managing time and billing system conversions. However, the same methodology cannot be applied universally from system to system. For firms about to embark on records management or conflicts management conversions, recognition of how these key firm systems define and manage data is critical to ensuring a successful transition.

What Makes Records and Conflicts
Data Conversions More Complex?

Accounting and financial systems are used to track client and matter data, billable hours, invoice clients, manage accounts receivable and accounts payable, develop and monitor budgets and measure the firm's financial performance. Virtually all information is centralized and organized according to client/matter number, invoice or batch number. This information is key to the business operations of the firm and can be quite voluminous, but it is very objective and managed consistently (or very similarly) from vendor system to vendor system.

Records and conflicts systems, on the other hand, manage a broad range of data and support operations that are not guided by long-established best practices and are not consistent from firm to firm or even from vendor to vendor. Migration of this data without a loss of information can be very difficult. Any disruption to operations resulting from an inability to access information can result in a breach of ethical responsibilities, loss of client-owned information and a lack of compliance with firm procedures such as retention of client files.

Records management systems may manage data including:

• Client and matter details;
• Physical file location information;
• Folder and box creation and activity data;
• Document-level metadata;
• Scanned and native-format electronic documents;
• Security/access details applied to physical and electronic information;
• Ethical wall information;
• Retention periods and rules for physical and electronic data; and
• Remotely managed content in document management systems, file shares and other firm applications.

Conflicts management systems are used to search for and report potential conflicts of interest and typically manage data including:

• Client and matter details;
• Information on parties involved with matters and the nature of their relationships;
• Lateral hire information that may not have resulted in formal matters;
• Details of conflicts waivers;
• Client engagement and disengagement letters; and
• Search history.

Shared Functions

While records management and conflicts management systems are fundamentally different and offer unique functionality, they both share characteristics that impact conversion planning similarly, including:

• Varying classification schemas. While records and conflicts systems ultimately relate most data to clients and matters, other relationships and hierarchies are often involved. A new system may employ hierarchical folders where none was present previously and make different assumptions about the relationship between storage files and inserts. The ability to profile documents may only be allowed beneath the folder level and not directly under the client or matter. Your firm may have conflicts-related data on involved parties stored as notes on client and matter records where the new system handles these relationships through relational database tables and needs to be parsed out to utilize the system's full capabilities.
• Multiple repositories. Firms undertaking a conversion typically draw in data from a number of sources. Even with an upgrade, the links to data in other repositories may have to be considered. For example, a record may be locked down and classified in the firm's records management system, but the actual record itself may reside in an e-mail archival or document management system.
• Manual and electronic. Even though records and conflicts systems automate these processes, manual steps are usually still employed at some level. There are often disparate spreadsheets and databases in use by pockets of users. Manual logs might hold valuable record delivery information. These sources of data have to be evaluated for their value.
• Risk management. Both systems play a significant role in firm risk management, ensuring compliance and mitigating risks that can lead to malpractice claims, reputation loss and client satisfaction issues. Data cannot be lost during conversion and downtime must be minimal. The firm cannot suspend conflicts searching for a few days or halt delivery of client files during a conversion.

Having a solid understanding of these factors prior to conversion planning will help ensue accuracy and minimize down time.

Planning a Successful Conversion

1. Take the time to meet with the firm personnel that actually use these systems on a daily basis. Understand their primary goals and how they're expecting to benefit from the migration. Consider new functionality as well as fixes for existing tasks. For example, have they been using cumbersome workarounds that can be eliminated via the upgrade? Can existing frustrations be minimized with proper planning? Have there been changes in policy or procedures that impact how they need to use the technology?

Also, be aware of overall strategic firm goals and initiatives that might impact these systems and how they are implemented.

2. With clear insight into the project goals, start by defining the data that is available and what you want managed in the new system. Look at all systems that house data, whether formally supported or not, including manual workarounds (e.g., assistant-created Access databases for offsite storage holdings). Consider how users plan to index and search against this information. A particular piece of metadata that was being tracked might not have a defined field in the database with the new system. Can it be mapped to a comment field? Does it need to be searchable? You must know enough about the front-end functionality of the new system to understand how end users will access and utilize the information being converted.

3. Identify the value of the data and determine what you want to have in the new system. When consolidating data from a number of sources, there may be duplicate information, but there is typically some value that can be drawn from each. For instance, while you might convert data on boxes in storage from a flat database kept by the records department that has the most detail on box content, a report from the offsite storage vendor may be the best source of data on the current status of the box and its recall history. The goal is to centralize all of the information in the new or upgraded system to minimize point of reference.

4. Review all integrations with other firm systems. Often, new client and matter data is brought over from the firm's accounting system or information is created directly from an automated intake process. While conversion will cover existing data, there must be plans in place to seamlessly capture day-forward data. Integrations between records and document management systems are frequently defined and conflicts systems may search other databases like CRM systems. Will this functionality be part of the initial rollout or added later in the process?

5. Calculate as much as possible using hard numbers ' number of boxes, rows in a database table, clients, matters, files, documents, parties, etc. These numbers can be your first point of comparison when evaluating the success of a data conversion. When converting tens or hundreds of thousands of records it can be difficult to manually review a representative percentage of the records.

6. Memorialize all mapping decisions in a mapping document. Documenting logic that needs to be built into conversion scripts can be very important if drawing from multiple sources. You may need to document the order of operation if you are pulling potentially duplicative data from multiple sources. Related party information from one source cannot be brought over until the client and matter records they relate to have been converted from another source in some cases.

7. Once the specifications of the end system are known, identify the sources of information and look at existing formatting versus the planned formatting. Will the amount of data fit in the intended field? Do dates exist in multiple formats? Do values such as state and country information have to match a format dictated by a lookup table to display properly?

8. Meet regularly with conversion technicians and functional users to ensure that expectations match. Define your timeline and the process by which conversion decisions will be documented and approved prior to any work beginning. Define responsibilities for extracting and formatting existing data as well as any cleanup that needs to happen before or after conversion.

Conversion Testing and Validation

Plan for at least one test conversion to allow your team to evaluate conversion decisions and unforeseen inconsistencies in testing results. Plan the timeline for delivering all needed data to the conversion team and when the actual conversion will take place. You may need to coordinate installation of a new application in conjunction with the data conversion. A new system may also require that some or all end users receive training before they can navigate the product and test adequately. There should be a defined time period for data testing and an agreed upon format for documenting and communicating any problems identified. Ideally, a single individual can coordinate all issues found during testing to eliminate duplicate issues and identify those related to user error. Consolidating all testing results will also illuminate common consistent problems like leading zeros that were lost on extraction while the data was stored in a spreadsheet format or sources that were forgotten altogether.

Have a testing plan and spreadsheet document to memorialize the testing and test reconciliation. Testers should be guided in exactly the type and volume of data that should be tested, and must differentiate between product functionality issues and data issues. Ideally, you should target a goal for the percentage of data to review, for example, testing 10% of the data as a valid representation of accuracy. However, with thousands of matters, that's not always viable. Another approach is to identify major representational classes to look at and to divide this work amongst the testing group. One tester may focus on client and matter records while another focuses on folder or party data. If testers have different levels of familiarity, one might be asked to focus on a particular practice area or the records from a single firm office. Users should be asked to document, field by field, that the converted data looks as expected when compared against the source data. Keep this information in a spreadsheet where testers can detail any discrepancies.

On a more technical level, perform table counts and compare the numbers (e.g., box table records, client table records, matter table records). However, it can be difficult to rely on this methodology because information may have been transformed on conversion according to the firm's specifications. Typical manipulations that may throw off data counts include de-duping, parsing or consolidation of data, and varying methods of indexing data.

Work with the conversion team to identify and apply fixes to errors found in the initial test conversion. Determine if you need to amend logic and conversion methodology. Any changes should be logged in the data-mapping document. After the next test conversion (or final conversion) is performed, prioritize testing identified issues, and then re-check a percentage of all data to ensure that fixes implemented to correct identified issues did not create additional errors.

Records management or conflicts management system conversions are not necessarily more difficult than other system upgrades, however they do require a little more up-front planning and attention to ensure a smooth transition and minimal disruption.