Contract migration is a common activity for CLM customers. There are many reasons a customer may want to migrate contracts into Coupa. Some common reasons include:
- To have Coupa as the customer's central repository for Contracts.
- To have all procurement contracts in Coupa available for purchasing and invoicing
- To have organizational-contract metadata available for reporting to drive both compliance and better decisions.
A contracts migration can have a lot of moving parts. Depending on the maturity of the organization and the current state of contracts, just gathering this contract data (let alone populating the template) may take a while. That's why it's critical to plan ahead.
There are a few components of contract migration that need to be understood prior to developing your test strategy. These are
- Volumes: How many contracts are you planning to load? A migration of 50,000 contracts would require a detailed migration strategy and test plan, while a migration of 500 contracts may not. The number of contracts to be loaded will directly impact your test strategy and the timelines associated with it.
- Legal Agreements and Attachments: Will all contracts be loaded with legal agreements and attachments?
- Data Dependencies: Loading contracts requires certain data to already be in Coupa (Suppliers, Users, etc). Will all of these data points be in place at the time of load?
Once you've identified the full scope of your contract load, it's time to develop your test strategy. There is no one test approach fits all, and you should look to create the right test strategy based on the scope of your contract load.
There are a few best practices that you should take into account when creating your test approach.
- Prioritize which contracts need to be loaded first. Load contracts that need to be in your system sooner than others. This could be for example, procurement contracts to allow purchasing from day 1. You can then sequence out your remaining batches to ensure they are all eventually available in Coupa. This consideration may not be relevant if the size of your contract migration is small (Ex. 100 contracts).
- Load contracts in smaller batches. Coupa recommends between 300-400 contracts at a time. This will allow you to isolate and error handle issues easier, while also speeding up load times.
- Stay organized! Create logical folders for your CSV, legal agreements and attachments for easy association and reference in the case of error handling.
- Do a full test-load in your test instance. If not possible, ensure at least 75% of the load has been completed in the customer's test instance first. Why? We'd like to minimize the level of error handling required in production. Testing these in full prior to loading in production reduces the risk of prod failures.
- Roles and responsibilities. The user executing the contract load must have the 'load published contracts' role.
- Ensure the user completing this load is included in every content group they are loading contracts for.
- Do your contracts have more than 10 attachments? Consider consolidating your attachments into one file if possible. Alternatively, consider loading the rest of the attachments manually in the UI.
- Contracts that have master agreements must be loaded separately, after the master agreement is published in Coupa. Keep this in mind when structuring your batches.
- 100MB is the size limit for each attachment within the ZIP file. 8MB is the file size limit for the ZIP that can temporarily be increased. If you need to increase this limit temporarily, please reach out to your Coupa Representative.
Regional/Country Specific Considerations
Do's & Don'ts
|Design Element||Recommended Design||Alternative Design||Risky Design||Rationale|
|Planning||After confirming the full scope of your load, incorporate migration testing time into your overall Contract Migration timeline. Align test loads with UAT milestone, and prod loads with MTP milestone.||
Confirm scope based on current state contract data that can most easily be transferred into Coupa. Create test plan around this subset. In parallel, gather remaining contracts (shared drives, in drawers, etc) and populate template for later phased load(s).
|Create timelines and testing strategies without confirming the current state and scope of your contract load. Alternately, don't plan at all.||Knowing what needs to be loaded is necessary in order to be able to identify the best plan around loading that data. A customer who needs to load 100 contracts can feasibly complete that test load within a day, while another with 10,000 may need a bit more time. That is why the planning and confirmation of your test plan should happen after the scope has been confirmed.|
|Prioritization||Test all in-scope contracts so that they are available on Go-Live day.||Prioritize which contracts need to be available in Coupa right away. Structure your test plan to ensure this subset of prioritized contracts are in their own batch load(s) and tested first before your prod load.||Test and load all in-scope contracts despite tight timelines.||Loading all of your contracts in time for Go-Live is ideal. However, this option is only possible if you've planned ahead to ensure that data population and testing are all aligned with your broader implementation timeline. If you haven't done this planning, it's critical to prioritize which of these contracts need to be in Coupa before the others. Not planning ahead, and not prioritizing, will result in a lot of last-minute frustration and error handling when it comes time to execute this load.|
|Batch Loads||For sizable contract loads (1000+), create batches of 300-400 contracts. Ensure batches account for data dependencies (Ex. Master vs Contract) and contract prioritization requirements.||Load all of your contracts in one load without any volume considerations.||Batch processing is an efficient way to process large amounts of data collected over a period of time. Loading all of your contracts at once may take a considerable amount of time to process, and may not take into account all of the various data inter-contract dependencies that may be present.|
Heat Map Assessment
|The customer will not be performing any contract migration activities as part of the implementation.||A contract migration testing strategy has been designed and confirmed.||Customer is still determining what their test strategy for contract migration should be.||The customer's testing strategy is considered as a risk.||The customer will perform contract migration in another system.|
Related Success Metrics and Value Drivers
- On-Contract Rate by Order Amount/Count
If these are key metrics for a customer's business, it is important to ensure contract migration is managed thoughtfully.