Migration to the new Console

GrapheneDB new Console

We are happy to say that our brand-new Console was launched a few weeks ago, and we have introduced a number of changes and innovative features, which have been generally available since March 2023. We have prepared a detailed article for you to explore and get an insight into what to expect.

What will happen with the legacy Console, users, and deployments?

We are opening the Migration period, spanning from June 2023 to November 2023, to allow all our existing users to migrate to the new Console. From December 2023 our old Console will run in legacy mode, and eventually will be discontinued. We understand that there are many parts of the migration process that depend on each user individually, and their personal business plans and expectations, therefore we have prepared a Migration plan, you’ll find further details about it in the next section.

There are two options that you can choose from when it comes to the Migration path:

• We do it for you. We create a private Slack Room, make a detailed plan with you, and do the migration in coordination with you.
• You do it on your own. You can follow the Migration plan below, but feel free to open a Support Case if you need help.

Migration plan

We’re opening a time window for migration which is 6 months long (end date 30th November 2023). This should allow you enough time to go through it smoothly, and with minimal impact on your business. Important to note is that the new Console supports Neo4j version 4, which means that when it comes to those databases running the 3.5 version still, the upgrade will be required before you can prepare for the migration of those specific databases.

Next thing to think about is how your Organization structure will look like.

What is an Organization?

An Organization is the top-level unit of GrapheneDB and is the main unit under which Environments, Members and API clients are managed, along with the Organization’s settings. Important to know is that billing happens at the Organization level. You can find detailed information on Billing in this article.

Next, important to know is that all databases are deployed into Environments.

What is an Environment?

Environments provide a way to group databases and configure the same network access rules (IP Whitelist, VPC peering), as well as configure access to a group of members of the Organization by assigning the color to Environment. More details on the Environments can be found in this article.

Roles and Permissions

In the Members section of the Organization, you can grant GrapheneDB users access to your Organization and assign Roles to enforce permission levels. Roles are:

Below is the representation diagram of the potential Organization structure. It includes 1 Organization, 3 Environments (development, staging, and production), 5 databases, and a total of 6 Organization members (Owner, Admin, three Operators, and Billing Manager) + 1 API Client.

Of course, you can also have a single Environment and deploy all your databases into one Environment.

I want GrapheneDB team to handle the Migration

We’d love to help you with the migration and make this process as smooth as possible. In the case you’d like us to handle your migration, feel free to open a Support Case. This is how the general process would look like in this case:

1. Make sure your databases are running version 4 of Neo4j. If you need to upgrade the version, you can do so directly in the database management interface. Alternatively you can also choose to migrate a subset of your databases if you prefer to wait until you manage to upgrade your 3.5 databases.
2. Set up your account in the new Console. Sign up to the new Console, choose a subscription and invite your team members. More info can be found here. If you choose a Gold Subscription plan, we’re offering to cover the cost for it for the 6 months, to allow you to adjust to new Subscriptions without repercussions.
3. Create an Environment and set up network access rules. More info can be found here.
4. Migration of your database to the new Console done by us (more details below).

Migration of the databases

We will take care of the migration of the database. We will schedule a time window that suits you best, you just need to communicate with us so that the detailed schedule and plan can be made. If you choose this option, where we do the migration, a huge benefit is that we will ensure that the database domain stays the same.

Outline of this process is below:

1. You stop the writes and inform us.
2. We put your database in read-only mode to ensure consistency.
3. We will create a new database in your new Organization (same database plan, version, name, plugins and custom configuration if applicable).
4. We will initiate a backup of the database that is being migrated, download it when ready and import it to the new database.
5. We will ask you to verify if data looks OK using Neo4j Browser.
6. When you confirm all looks OK, we will delete your origin database.
7. We will switch the domain from origin to the new database and ask you to connect your application.

I want to handle the Migration on my own

In case you’ll do the migration on your own, keeping the same Connection URL of the database is not possible, unfortunately. The possibility of keeping the same domain is only available if we do the migration for you. Below are the detailed steps to take to properly prepare your database for migration and migrate it to the new Console.

1. Sign up to the new Console, choose a subscription and invite your team members. More info can be found here. If you choose a Gold Subscription plan, we’re offering to cover the cost for it for the 6 months, to allow you to adjust to new Subscriptions without repercussions.
2. Create an Environment and set up network access rules. More info can be found here.
3. Upgrade your database to supported version (Neo4j version 4) if needed.
4. Create a new database in the new Console, with the same plan and version. You can find the article about it here.
   • If needed, add Plugins and custom configuration
5. Stop the writes on your original database and put the database into the read-only mode to ensure consistency.
6. Initiate a backup of your original database, and download it when ready.
7. Import a downloaded backup to your new database. You can find the guide about it here.
8. Verify that the data is properly there, using Neo4j Browser. Here’s how you can do it.
9. Connect your application to the new database. Keep in mind that the new database has a new Connection URL, which you can find in the Connect tab of your database management interface.
10. Finally, when you make sure all is OK, you can delete the origin database from the legacy Console.

Legacy Console - What happens if I don’t migrate?

If it does not work for you to upgrade the database version, those databases can stay in our legacy console after the mentioned 6 months (after 30th November 2023), but the legacy console will have limited operation abilities, meaning that below listed operations will be discontinued:

• Scheduled Backups
• Change plan
• Create new database
• Empty database
• Extensions
• Import
• Public API

The following operations will remain to be available, to ensure that users that are still in legacy Console are able to complete the migration:

• Upgrade version
• Clone
• Restart
• Manual backups

Network configuration will still work, and will remain until the legacy Console gets discontinued.

Keep in mind that legacy Console will be discontinued at some point in time, which will be communicated in advance, and for that reason as well we encourage you to consider migrating to the new Console.

If any of the mentioned details in this document are unclear, need clarification or you have any questions, please feel free to open a Support Case, we will be happy to assist!