When upgrading from Confluence 6.2.0 to Confluence 7+, how do attachment content properties migrate?
Asked by P:

When upgrading from Confluence 6.2.0 to Confluence 7 or higher, how do attachments stored in the database with custom content properties get properly migrated over to the file system ?

In our version of Confluence, attachments are currently stored in the database along with a custom content property using the[ContentPropertyManager.setTextProperty()](https://docs.atlassian.com/atlassian-confluence/6.2.0/com/atlassian/confluence/core/ContentPropertyManager.html#setTextProperty-com.atlassian.confluence.core.ContentEntityObject-java.lang.String-java.lang.String-) and [ContentPropertyManager.getTextProperty().](https://docs.atlassian.com/atlassian-confluence/6.2.0/com/atlassian/confluence/core/ContentPropertyManager.html#getTextProperty-com.atlassian.confluence.core.ContentEntityObject-java.lang.String-)

For database developers reading this, you already know this content property is stored in the OS_PROPERTYENTRY table under the "text_val" column

**My question:** When upgrading from Confluence 6.2.0 to Confluence 7 or higher, will our custom content property migrate into the file system or remain in OS_PROPERTYENTRY?

If it migrates to the file system alongside the attachment itself, can I still use ContentPropertyManager's getter and setter ?

Also, is there some kind of a script that can check whether all the content properties associated with an attachment have been properly migrated during an upgrade from the database to the file system? Checking it works correctly for a few attachments should be simple, but if there are over 10000 attachments then checking if each one's associated content property was properly migrated would become cumbersome. A script that could iterate through all attachments in the database and verify the content properties associated with each attachment were properly migrated would save a lot of time.


Answers:
author: Moses Thomas
body: [@P](/t5/user/viewprofilepage/user-id/660629) Confluence 5.4 and earlier gives administrators the option to store attachments in the database that Confluence is configured to use.

By default Confluence stores attachments in the home directory (e.g. in a file system) for version since 5.5 and above.

[Class FileSystemAttachmentDataDao](https://docs.atlassian.com/atlassian-confluence/6.2.0/com/atlassian/confluence/pages/persistence/dao/filesystem/FileSystemAttachmentDataDao.html)

Now storing attachments in the database is not an option for your confluence version it is(Deprecated). That means that you are not given the option to store attachments in the database.

Back to your question, it says in [Interface ContentPropertyManager](https://docs.atlassian.com/atlassian-confluence/6.2.0/com/atlassian/confluence/core/ContentPropertyManager.html?&_ga=2.21644991.528565719.1592646745-1655680451.1589440275#setTextProperty-com.atlassian.confluence.core.ContentEntityObject-java.lang.String-java.lang.String-) instead of using this interface you should use [Class ContentProperties](https://docs.atlassian.com/atlassian-confluence/6.2.0/com/atlassian/confluence/content/ContentProperties.html) and the class content properties is also supported for confluence 7.0 [Class ContentProperties conf v.7.0.x](https://docs.atlassian.com/ConfluenceServer/javadoc/7.0.2/com/atlassian/confluence/content/ContentProperties.html)

In addition your custom content property will most likely not migrate into the file system it should remain in OS_PROPERTYENTRY; but i suggest your try to upgrade in the test environment to certainly verify this before doing it in the production environment.

There is also information here on migrating attachment from DB to file system should in-case you are still using attachment stored in DB. [Attachment Storage Configuration](https://confluence.atlassian.com/doc/attachment-storage-configuration-166876.html)

NOTE if you are already using attachment on file system then the migration pop up with not appear in **Attachment storage**setting.

Best regards,

Moses


Tags: database

development