Migration to Custom Fields V2 | Targetprocess - Enterprise Agility Solution
3 years ago

Migration to Custom Fields V2

Custom Fields V2

Flexibility and customization always were key features of Targetprocess. That’s why one of the most used features in Targetprocess is Custom Fields. Unfortunately, in more than 10 years since Custom Fields were introduced in Targetprocess, their implementation became inefficient for the number of people that are using Targetprocess and the amount of data that application is storing. In addition, with old implementation of CFs it is not possible to implement efficient access to Custom Fields in historical data. 

Benefits of Custom Fields V2

For some time, we were working on new more efficient version of Custom Fields that would allow to access the historical and cumulative reports of Custom Fields. 

We were able to come out with implementation that works 2-5 time faster for queries related to Custom Fields across all our cloud customers:

Constraints of Custom Fields V2

To migrate to new Custom Fields V2, we needed to apply new constraints to them: 

  1. For V2 Custom Fields it is not allowed to create Custom Fields that have the same name and different type. For example, if there is a Custom Field named "test" for User Story with a type number, all other Custom Fields named "test" should have a type number in the system. 
  2. Maximum name length for Custom Fields is restricted to 100 characters (previously it was 255). 

Migration progress

More than 99% of Custom Fields across all our customers are valid for these constraints, and we were able to seamlessly migrate them. 

Unfortunately, semimanual actions are required for migration of 1% of Custom Fields that is left. It may also require some communication with users. 

Depending on case,  these actions may include the following: 

  1. Changing data type of fields. For example, there are two Custom Fields named "test" with a number type for User Story and a text type for Bug. In case values for a bug Custom Field actually contain a number, we can convert the type of this Custom Field to a number and no data will be lost. 
  2. Renaming Custom Fields. When values under conflicting Custom Fields are incompatible, we need to rename some of conflicting Custom Fields. For example, there are two Custom Fields named "test" for User Story (number) and Bugs (text). Values for bugs cannot be converted to a number. In that case, the only way to resolve conflict is renaming Custom Fields. 
  3. In some cases, when conflicting Custom Fields are not used anymore, they can be removed. However, customer confirmation is required for this action. 

Our support already started contacting customers that have conflicting database. Resolving conflicts and migrating Custom Fields to V2 will also allow us to remove old implementation from the code, simplify codebase and deliver new features faster. 

 

Capterra Top 20
Capterra Top 20
Project Portfolio Management
May-20
GetApp Category Leaders
GetApp Category Leaders
Project Portfolio Management
Jul-20
GetApp Category Leaders
GetApp Category Leaders
Roadmaps
Jul-20
Software Advice FrontRunners
Software Advice FrontRunners
Product Management
May-20
Software Advice Recommended
Software Advice Recommended
Product Roadmap
Mar-20
Software Advice Customer Support
Software Advice Customer Support
Project Portfolio Management Software
Jun-20

Subscribe to the latest updates

Thank you!

Сheck out latest blog posts: Show all