Managed to overcome a NUMBER of other errors thrown up by the migration tool but stumped on this one..
Seems to fall over when converting DynamicProperties?. What is the best way to debug this?
[16/02/2010 08:36:26][Error] Failed to convert links, reason:Object reference not set to an instance of an object. at EPiServer.DataAccess.DynamicPropertiesDB.LoadTree() at EPiServer.DataAbstraction.DynamicProperty.ListTree() at EPiServer.Migration.ConvertLinks.UpdateDynamicProperties() at EPiServer.Migration.ConvertLinks.StartConverting()[16/02/2010 08:36:26][Warning] Failed to convert links therefore migration is stopped. Check that target site is running and then run migration tool again and choose continue existing process[16/02/2010 08:36:26][Information] Migration stop requested[16/02/2010 08:36:26][Warning] Some pages failed during migration. See C:\EPiServer\Sites\TemporarySite\MigrateLinksErrors.txt for detailed information[16/02/2010 08:36:26][Information] Migration stopped
Object reference not set to an instance of an object. at EPiServer.DataAccess.DynamicPropertiesDB.LoadTree() at EPiServer.DataAbstraction.DynamicProperty.ListTree() at EPiServer.Migration.ConvertLinks.UpdateDynamicProperties() at EPiServer.Migration.ConvertLinks.StartConverting()
Can you check that your CMS 5 site is running without any errors?
Both the old CMS 4 site and the new CMS 5 site work fine before the migration process..
Do you have any dynamic properties of a custom property type? If yes, do you get a succesfull migration if you remove them?
I will try this later, cheers
Removing any DynamicProperties whose types were CustomProperties then retrying the migration tool worked for me!
I usually create library project(s) that contains classes for all custom properties registered in the EPiServer 4 site and add it to the bin folder for the EPiServer 5 site before migration.
The only thing the class need to do is to inherit from the correct base class to get the right data type. It must of course has the same namespace and class name and the assembly name must also match.
The benefit from this extra work is that it prevents the Migration Tool from createing renamed dummy properties for you (that you have to rename manually later).
It could possibly also work to solve this problem too.
So if you just use the same assembly name, namespace, class, and type, the migration tool will use that as the property type for custom properties?
Yes, the migration tool checks first if custom properties are available on the target site and if not creates dummy custom properties and change the assembly and class name in the database to match the generated code.
Very cool! Wish I'd known that before.. Learn something new every day! Thanks for sharing Fredrik! :).