If you want to migrate from another CMS, then the flexibility and already available modules for transmogrifier will be a much better match. You'll also have to do much more work anyway by mapping fields/content/concepts/structure from another CMS to Plone.
As @mauritsvanrees wrote, him and me have tested and contributed to collective.exportimport in the last few weeks to fix the common migration case of Plone 4 with Archetypes content to Dexterity Plone 5.2 content.
technical thingie:
Collective.exportimport uses under the hood the (de-)serializers of plone.restapi to export and import content. But there are field name and small structural changes between the Archetypes and Dexterity serializer code. With a check box on the export content form you can activate some extra patches/renames on the exported json from Archetypes content items so it matches the Dexterity exported json and both should import the same using the import_content dexterity deserializer.
We'll have to add more documentation as it is a kind of 'manual' ETL migration for smaller projects. You have to stick to a certain order and some best practice, but with it you can migrate most of the default content.
We also together 'fixed' some of the 'only for small sites' limitations by adding a sequential json reader/parser and support also json files from the server. With this I was able to migrate 8Gb of .json serialized Files (base64) and as Philip writes above he now wants to take on 80Gb 
It's kinda amazing that the plone.restapi improvements made in the last years to support the new Volto frontend in Plone 6 now indirectly also contribute to having this simplified ETL migration add'on. This can skip a lot of unknown unkowns in the migration of older sites to Python3 Plone 5.2/6 for the bulk of default content. to quote Philip:
But starting fresh without any baggage is a great benefit of exporting old data and importing it into a new site. Not importing what you don't need is much easier that trying to get rid of it.
This has bitten me very hard with a previous attempt last year to migrate this Plone 4 site with in place migration. The site is 13-14 years old, was and has collected so many small rabbit holes and bit rot, that you keep fixing edge cases in your migration code until it has sucked all motivation out of you to face another new traceback. 
I'm just skipping old Style Collections (Topic)and will recreate them manually. There are like 40 of them in this project where most of them are small variants. You can pick and choose the most efficient route for individual CT's. fix/customise the export/import code, recreate manually, modifiy the .json.
The 'feedback loop' with collective.exportimport is also much quicker. Export, import, something breaks, fix a field modifier, or test by modifiying the json. export/import again, maybe on a part of the json. But I have some 'feature requests' to improve on this further, for example see import_content: Dry run option with more verbose deserializer validation feedback · Issue #15 · collective/collective.exportimport · GitHub.
