Hello Plone community. I am new to Plone and am having trouble upgrading it. We are running Plone 3.2.3 on Linux (OpenSUSE 11)...all super old. I've taken over looking after it as the one who set it up is no longer with the company.
I posted a question in this forum last year but could not really resolve the issue at the time as more important matters came up and this project got shelved. I am looking at it again now.
Updating the current server seemed an impossible task due to the age of the server as well as the current version of the Plone install. We only use the software as a sort of secured file sharing service within our company. Secured at different levels via Security Groups from Active Directory. Rather than trying to update anything. I opted to just set up a brand new server, install Plone 5.2.2 and look at getting the data migrated over somehow.
Ive spent a couple days going through forums and google etc but have been unable to find the answer I am looking for which is, how do i export all the documents and folders from 3.2.3 and then import it in to 5.2.2. I have seen mentions of the Transmogrifier which might be useful?
I am not proficient with Plone or coding at any level unfortunately.
Could anyone perhaps point me in the right direction or have any suggestions?
Here is an excerpt from a tender where I documented the migration approaches for a potential customer.
The third approach is what we usually do in larger customer projects. We are currently using it for the migration of ugent.be with about 90.000 content objects (50 GB of data).
Data migration is only one part of the story. For Plone 5.2 under Python 3, you clearly need updated versions of your add-ons. Don't expect that anything will work on Plone 5.2. A migration of a more complex Plone site requires experience and coding skills and is nothing for a beginner. I doubt, ask a Plone solution provider with related experience.
Migration approaches
In-place Plone migration
Plone 5.2 supports a so-called “in-place” migration which is usually the right choice for simple sites with simple content-types and standard add-ons like PloneFormGen. The database file of Plone 4.3 is migrated in-place and transformed into a Plone 5.2 compliant database file. This is the approach in theory. It is often necessary to perform additional work and additional migration steps to migrate an old Plone database to Python 3 format - in particular when the Plone site has a certain age and history (which often implies a lot of cruft and old configurations that can break or interfere with the standard Plone migration). We use this migration approach only for small and simple sites.
Export/Import using Transmogrifier
The export/import approach allows us to perform a clean export of the content from the old site and to perform a clean import into a fresh Plone 5.2 site. So the new site will not contain any cruft content or obsolete configurations etc. The export of the is usually accomplished using the collective.jsonify add-on for Plone which basically exports all content objects and their metadata as JSON - one JSON file per content object. We also have supplementary code to export additional Plone settings or e.g. the Plone users and groups (if need, unless users and groups are maintained in LDAP or Active Directory or something similar). The exported JSON files are the foundation for a fresh import using the Plone Transmogrifier tool. Transmogrifier is basically a processing pipeline for piping the JSON data into Plone. The import can be customized using so-called “blueprints” in order to inject project-dependent dependencies, filtering steps, etc.
Export/Import using a custom migration pipeline
In our larger Plone migration projects, we often use a variation of the Transmogrifier approach. The export of the data and content from the original site is also done using the collective.jsonify add-on. The exported JSON files are then being imported into a migration database (we use ArangoDB). The migration database allows us to perform a partial import, query, and inspect the migration data in order to work on migration aspects and problems more easily than searching to Gigabyte of JSON files on the filesystem with operating system related tools like “grep”). The import is done using a custom migration package (which is to 80% generic for most Plone migrations, the remaining 20% are project-specific adjustments or additions because every migration is different). Our migration package allows us to run partial migration in order to test migrations more flexible. E.g. the migration package allows us to import a subset of content (either one or more folder or only specific content-types). This is very handy and time-saving. Migrating a large Plone site with a lot of content can take many hours. So testing changes on a particular feature with a subset of the data in advance is always better than having a failure on the full migration set after some hours.