Fleet manager: document migration#1043
Conversation
There was a problem hiding this comment.
actually this page is outdated. There is a separate issue to fix it
SeBBBe
left a comment
There was a problem hiding this comment.
Looks good overall, though I find the different levels of headings a bit confusing.
One-click vs wizard. Auto vs manual. Steps vs migrate to new/existing. Would be nice to find a way to flatten/simplify the structure.
I ran it through the neo4j-editorial skill which produced some valid points as well.
Well it is a multistep process with some alternatives. We could reduce the contents since it is also in the wizard but I have no quick idea on how to flatten the whole. Maybe the one-click will go away, that would be one level less.
Nice! Did you do that in Gemini as presented recently? |
| You can transfer your data in two ways: | ||
|
|
||
| * *Automatic* (recommended) – Fleet Manager stops the database, creates a dump, and uploads and imports it into Aura for you. | ||
| * *Manual* – you create and upload the database dump yourself using `neo4j-admin`, following an online checklist. |
There was a problem hiding this comment.
Should we link to migration.adoc here? I think it's currently not entirely obvious that this page concerns the automatic flow(s) only.
There was a problem hiding this comment.
the "online checklist" in this sentence refers to the manual data transfer step of the migration wizard, so it is self-contained. I see the migration.adoc as kind of external to this page.
No, with Claude code (https://neo4j.slack.com/archives/C02AS3DQF/p1781118664756449) |
Co-authored-by: Jessica Wright <49636617+AlexicaWright@users.noreply.github.com>
…t-migration Some additions clarifying CE migration and prior and next steps
|
This PR includes documentation updates New pages: Updated pages: |
| Fleet Manager can guide you through migrating a monitored self-managed Neo4j deployment to Aura, directly from the Aura console. | ||
| The migration is driven by a wizard that helps you check compatibility, choose a destination Aura instance, and transfer your data. | ||
| There are different ways to migrate data from a self-managed Neo4j deployment Community Edition to Aura. | ||
| You can do it manually as described in xref:tutorials/migration.adoc[Migrate from self-managed to Aura], using `neo4j-admin` to create a database dump and the manually uploading it to an Aura instance. |
There was a problem hiding this comment.
| You can do it manually as described in xref:tutorials/migration.adoc[Migrate from self-managed to Aura], using `neo4j-admin` to create a database dump and the manually uploading it to an Aura instance. | |
| You can do it manually as described in xref:tutorials/migration.adoc[Migrate from self-managed to Aura], using `neo4j-admin` to create a database dump and then manually uploading it to an Aura instance. |
| Automatic workload analysis will be available in future versions of Neo4j. | ||
| ==== | ||
| Decide whether you want Fleet Manager to check your workload for compatibility or if you want to do this manually. | ||
| You can allow Fleet Manager to collect data about your workload for 24 hours to gauge whether your workload is compatible with Aura. |
There was a problem hiding this comment.
Maybe I'm out of the loop since I just came back from vacation but last I heard we decided to offer this only to versions with log-independent query obfuscation (RUN-575). This will land in 2026.07 so that will be a requirement for automatic workload analysis (unless something changed).
There was a problem hiding this comment.
I think it is controlled by a new FM setting (SETTING_MIGRATION_WORKLOAD_ANALYSIS) now which in turn is only available to enable for query-obfuscation enabled deployments. Something similar to https://github.com/neo4j/upx/pull/11573 should be done to make it available for latest releases.
part of NOM-302