# Feature SSI-452 - Migrate a custom field of type List to a custom field of type Hierarchy on demand

Project: Stream Storage Integrations
Status: new
URL: https://community.openproject.org/work_packages/SSI-452

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Target versions | Product Backlog |
| Votes |  |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

_No work packages_

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module | Administration / Custom fields |
| Feature Flag |  |
| Requires doc change | Yes |
| Enterprise plan |  |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups |  |
| Accessibility | No |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | OP Dev Titan Team |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work |  |
| Labor costs |  |

## Description

**As** an admin  
**I want to** selectively migrate my data in a custom field of type list to a custom field of type hierarchy  
**so that** I can use the new data type without having to reenter all my data.

**Acceptance criteria**

*   On an existing custom field of type List there must be an option to initiate a data migration to a custom field of type hierarchy.
    
*   (An existing custom field of type list has a visible deprecation note.)
    
*   When creating a new custom field from an existing list:
    
    *   the new custom field must be configured right next to the origin custom field in work package forms or project attribute sections.
        
    *   the originally assigned values must match the newly created values.
        
    *   the name of the new custom field must hint at the origin specifically
        
        *   use `{origin_name} new`
            
    *   the origin custom field MUST NOT be deleted right away. The deletion is a user decision after checking the system for correctness and consistency
        

**Permissions and visibility considerations**

*   Currently custom fields of type hierarchies are a paid feature. We should either
    
    *   make hierarchies part of the community plan
        
    *   make the option of creating sub items be part of an enterprise plan and the rest a free feature
        

**Other considerations**

*   Technically we could also migrate into Weighted item lists, providing something like a default weight of `0`. This could still be a good help for initiating a weighted item list out of an already existing list.
    
*   The migration functionality could also open the possibilities of creating weighted item lists our of hierarchies and vice versa (with data loss of shorts and weights).