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.