I have site column named : "Review Type", (Text field):it's a choice betewen defined text like : Annual, Adhoc, Major Changes..., now I want to change it to choice field(Annual, Adhoc, Major Changes...), I programmatically did it but the problem is that I have to delete the library and reactivate the feature, I don't want to lose the content in all the fields including this field. Help please.

  • Maybe an idea of a script how select DDL"Annual" if text ="Annual" ?
    – BKChedlia
    Commented Jul 4, 2016 at 14:05

1 Answer 1


Your question doesn't give much details on your environment or how the list/columns where originally created, so I will have to guess. As you may have guess, there is no out-of-box functionality to allow such field type change (as least afaik), so you will have to resort to a custom "migration".

There are two opposite cases that we should consider:

Option 1: the list/content type/columns were originally provisioned by a feature.
In this case, your best guess would be using feature upgrading to define an upgrade path that will migrate your data. As a basic idea you should:

  • Create a new column with a different internal name from the original one. This new column will be the choice field we will copy the data to.
  • Loop on all the items in the list and copy the values from the old to the new field. .SystemUpdate() can help to avoid changing the audit info on the items during this process.
  • Delete the old field.

Option 2: the list/content type/columns were originally created manually. I would still follow the same logical approach I suggested for Option 1), with the obvious difference that here all the steps should be done manually.

  • Create the new choice column using SharePoint UI. Give it a different display name for now, you can change it later.
  • Write a simple one-use script that will loop the data in the list and perform the copy. You don't need anything fancy - it will be used just once and never again.
  • Delete the old field and rename the new one.

Sadly, both approaches present some issues you must be aware off.
First, is the copy process. Depending on how much data you have to "migrate", the process could potentially take a lot of time. Before taking any action, you should consider if you will need to have the copy running at a different time to avoid impacting end users. If that is the case, a batch process running overnight may be an idea.

Second, and most important, is that you will end up with a different field from the original one. This means that the field "identity" - the static/internal names - will be different too: you will therefore need to fix any logic you may have lingering around that relies on the old field names. Probably you would have had to fix that logic either way, since now the underlying type of the field has changed, but keep this in mind anyway.

As a final note, I would point out that as a desperate final resort if all else fails, you could try to restore the old field names if you use a two step migration approach:

create a work field -> copy the data to the work field -> delete the old field -> create the new field using the old internal name (now you can since the original field is no longer there) -> migrate the data from the work field to the final field.

I would use this one as a last resort. As I already said, probably any code that made use of the field will fail anyway since now the field is of a different type, so probably you are best to try and fix the logic consuming the field rather than trying to make the field "seem" the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.