Hi,

the data migration should remove the CatalogContentDraft instances when it creates the corresponding versions in the new version system. Not all the drafts are migrated during the upgrade (migration step) though. "Non-active" versions are migrated using a scheduled job (see http://world.episerver.com/documentation/upgrading/episerver-commerce/9/)

If for some reason you still have CatalogContentDraft instances in DDS after completing all the migration steps, those will not be used by Commerce and should be safe to delete like you suggest.

Note that you can run DBCC SHRINKDATABASE after deleting the draft version. It can reduce your DB size quite significantly 

Is there a way to somehow increase timepout for this deletion? I'm getting timeout because there are very many objects.

Regards,
Giedrius

Does it time out on the Count() or the DeleteAll()? Skip the count if you don't need it, I suspect it will try to load all data into memory. If the DeleteAll times out, you can try increasing the deleteAllOperationTimeout setting of the episerver.dataStore/dataStore config section (see http://world.episerver.com/documentation/Class-library/?documentId=cms/9/CA8FBF5C)

Or try to loop the items and delete individually instead (it might help to select just the Identity property then maybe it won't load the entire object).

Hi, 
It times out on deletion. I'll try to increase timeout

It's generally bad practice to do something in SQL if you can do it in APIs, but in this case you can delete those old versions from tblBigTable (filter for StoreName). Remember to backup your databases first. And IISReset will be needed after that 

In this case I would really try everything to avoid direct SQL. It risks leaving orphaned items of other types behind, items that were referenced by the drafts. It will also miss associated tblBigTableReference rows. Possibly it could be better to delete from the CatalogContentDraft SQL View, but I'm not sure that would take care of referenced items either.