Peace and blessings. Once again, it's your boy, Mr. Wildenfree. As you know, I've been away
for far too long already, however, I'm coming back with
some genuine treats for you all. So hopefully, this is the video that
answers a question you've had when it comes to working with Notion templates. Now say you've downloaded one of
my templates or any of the other templates provided by the Notion
Creator Economy, and you notice that there's a brand new version of that
template that has now rolled out that you wanna take advantage of. This becomes critical when Notion starts
to roll out newly released features Much like how Database Automations
have just been announced. So what I'm gonna show you today is how
you can take your existing Notion systems and get the data from inside of those
databases transferred into the brand new versions of those same databases. So let's go ahead and hop right into it. So we're talking about database
upgrades and migrations. Let's consider two parallel systems built
in Notion that serve the same purpose. We're gonna use the Music
O S as an example here. Say we have version one
of this template system. So that's the Music OS 1.0. And then what we want to do is
upgrade to the new Music OS+, which will be version 2.0 of that system. Now, what I have displayed here is
the visual representation of these two systems in their entirety. And what I mean by that is when
you look over to the left, you'll see a mermaid flow chart that
represents the five databases that exist inside of the Music OS system. And to the right we have a flow
chart that represents the eight databases that exist inside of the
Music OS+ system, a k a version 2.0. Another really important thing to
recognize here is that all databases that exist in the old system also exist
in the new version of that system. Now, this is for optimal data integrity. And what I mean by this is, that all of
the data in version 1.0 already has a predefined location to go in version 2.0. Now, this ensures that we are able
to keep all existing data from those databases, but it also ensures that we
have the opportunity to maintain the existing relationships that exists between
each database in both of those systems. Cool. Now let's flow right along. Now, as I've mentioned, this is typical
when you're working with template systems, or upgradable versions, using this table
that's currently displayed, I'm giving an example based on templates that I
have created to offer to the community. So you'll notice I have the Simple Music
Dash, which provided downloaders of this template with the records database
and the album's database alongside an actual page to operate out of. Right now we're just focusing
primarily on the databases themselves. From there, Music OS was an improvement
on top of the Simple Music System by providing an additional three databases,
which provided databases for the community to structure and organize their artists,
a word bank, and even their audio plugins. From there, what's on the horizon
will be the Music OS+ system, which builds on top of that to provide
yet another three databases. So including the artist's, word bank
and audio plugins, databases, Music OS+ will go beyond that to provide you with
the Music Tags database, the Music Gear database, and the Tech Stack database. Now using that as an example, say there
is a community member who is using the current Simple Music Dash system. They want to be able to take their data
from the records database and their Albums database and transfer that over
into the Music O S system, keeping the data integrity intact, making sure that
all of their records and all of their albums and the corresponding relationships
between them are maintained when they transfer over to that new Music OS system. Now, let's say that there is a
community member who is currently using the Music OS system. They will also want to transfer over
their data from their artist word bank and audio plugins, databases,
into that new Music OS+ system that will have those additional benefits. So that is effectively our goal
with today's lesson is to provide a means for you all to transfer your
data from one previous version of a system into a new and improved system. And this goes for anybody's template
structures, it's not just with templates that I provide to the community, but
also any other Notion creator out there who is providing you all with Templates. Hopefully they have structured
their templates in such a way that it makes it easy for you to
migrate your data from your existing version into a newer, improved
version of that template or system. Now I want to highlight some
goals for a data migration. We wanna make sure that the existing
data gets mapped to the appropriate property columns in the new system. We want the relation properties to
keep their relevant connections. We also want important changes from
our first system to not be lost once we transfer that data over to the new system. Now, an example might be new template
pages that you've added to this particular database or system,
additional views, or linked views of said databases and new property columns. So these are the things that we're
going to discuss here in a moment. And while we may not be able to
automate all of those, I will break down for you what will work it comes
to transferring data and getting that data merged successfully into that new
system and what you might need to have a bit more of a manual interaction with. So let's keep moving on. Now this is the most important thing. In order for this to work, the entire
system must have been duplicated altogether in its entirety. Once the system has been created,
every database that is related to one another should exist inside of
the same parent page, and that parent page is what should get duplicated. And ideally, both the original
system and the new system have been duplicated in this way, but that's
ideal, I'm not sure if that's required. If you are using a system that you've
derived from a template, then this is likely to be the case already. Now, duplicating or creating one
database at a time and then remapping the relations based on the system's relational
database settings will not work. So what I mean by that is,
say for instance you have your existing Music OS setup. What you won't want to do is gain
access to that template page and then try to copy and paste or duplicate
individual databases to then try to migrate to your own system. You'll want to have that entire
system duplicated and transferred over into your workspace. That will ensure the highest chance
of data integrity when it comes to migrating your data to that new system. And below, I just have a callout that
represents that entire system existing inside of a parent page, that you will
then duplicate into your own workspace. Now moving right along. What we have here are migration behaviors. What I'm representing here with this
table is how changes you might have made in the original version of that
template or system will impact the migration behaviors when you transfer
that data from one version to the next. So first off, we'll address any changes
that still allow for the data to map appropriately into that new version. So say for instance, you have changed
the order of the properties, or you have renamed certain properties,
or you have changed a property type to a compatible format. And what I mean by that is like
changing a Text property to a Select property or a Select property
to a Text property, or a Select property to a Multi-select property. If you change it to a compatible
property type, all of that data will migrate successfully without any
issues, and you'll see it represented once you transfer that data over. Likewise, with my testing, when you
rename a property type, so long as the data within remains the same,
the property types remain the same, and the context or the relevance
of that title remains the same. The data should transfer over
without creating a new property field, but merging that data and
representing it appropriately. Now when you create a brand new
property in your original database, that is one of those actions or change
behaviors that upon migration will result in a new property being created. Now keep in mind, this property
will likely be hidden by default, so when you do this, make sure
you check your hidden properties. Another thing to note here is that
typically you'll have to have some value represented in that property
field in order for that data to get transferred over to that new version. Now let's talk about unique behaviors. Let's say that you've changed one
of those original property types into an incompatible property type. The unique behavior that will happen
here is that when you migrate that data into that new version of the system, it's
gonna look like that data has disappeared altogether, like it did not transfer. However, if you take that new version
of the template and you go to that specific property column and you
convert it back into a property column that is compatible with the original
version of that system, then you will see that the data is maintained. So that's incompatible. Property type changes. Next, Status property columns. If you have a Status property column
on both versions of a template, but the new version of the template doesn't
have all of the options from the previous version, say you've added some
additional options, those new options won't immediately get transferred over
to that new version, so you will have to recreate those status options before
you do the transfer to make sure that they get paired when you merge the data. Lastly, we'll go over changes
that do not occur upon transfer. And what that would be like I mentioned
before, is your new template pages if you have brand new template pages
that you've added to the original version that are unique to your
setup, those won't be represented on the new versions of that template. And just transferring your data
won't automatically merge that template to the new system. Any automations from one
database to another, the upgraded version of that won't transfer. Database views, unique database views
that you've configured will not transfer to that new version of the database. Linked views of database
unfortunately will not transfer. You will have to recreate new linked
views wherever you have instances of that database represented. Lastly buttons referencing
relational databases. Say for instance, you have buttons
inside of database pages that when you click on it automatically generate
a relation property to one of the existing databases in that system. When you transfer that data
over into that new version, you'll have to upgrade those
buttons to correspond with the new relations in that new system. Cool, so hopefully this was helpful
to you all just to kind of talk through it, to visually see, the
things that we need to keep in mind while we're doing this data transfer. And so now I finally get to show
you all exactly how this works. So what I'm going to do is take the
data from version one and I'm going to transfer it over into version two. This is how you can do it
within your own system. Okay? Now, when you are working with your
existing data, say that this records 1.0 had 300 different unique pages in it. What you will want to do is load
all of the pages so that you can select them all at once. When you hover over the property
header, if you go all the way over to the left hand side, you'll notice
a little white square that appears. Click on that white square and
you'll select everything inside of that database that has been loaded. So once you've done that, you're
gonna click on these three dots in the dynamic menu that appears, and
then you're gonna click on move two. Once you do that, you're going to
identify that new database that corresponds with the database
you're currently working with. So, as an example, going from
Records 1.0 to Records 2.0. And if they're not named that blatantly,
just take a look at the actual breadcrumbs underneath the title to help you navigate
where you need to go with this new system. So I'm taking the proper steps to
select everything in Records 1.0, and I'm now moving them all to Records 2.0. What I want you all to pay attention
to is notice how the artist's property is a relation property. And I have artists
selected in these fields. So when I go ahead and I click move to
and I transfer that data over to this new database, notice the artists are now gone. I don't want you to panic. Okay? What I'm going to do now is go
over to the artist's database and I'm going to do the same thing. I'm going to transfer the data
from the artist 1.0 database into the Artist 2.0 database. So that's what we have
represented down here. I'm gonna go ahead and
give this some more space. And now we have Artist
1.0 and Artist 2.0. I'm gonna do the same thing. I'm going to select all of the database
pages that exist within that database. I'm going to click on the three dots
in the dynamic menu that appears, I'm going to click on "Move to",
and now I'm going to transition those items to the Artist 2.0. And now watch. Once I do that, when I scroll
back up, you will see that the artists and the relations between
that data were maintained. So I was actually able to keep the
relationship between two different databases in a previous system and
migrate them over to a brand new system and keep those values the same. So that's how we wanna do our data
transfers for optimal data integrity. Now I'm gonna undo that because I wanna
show you something really quickly. The reason why this Records 2.5 database
exists is because I wanted to show you all, I duplicated this records database
independently of the entire system, and then I went back in and I mapped it
to the corresponding databases, right? So the artist database, the albums,
database, you know, et cetera, et cetera. Now I'm gonna do the same thing. I'm gonna take these records from 1.0
and I'm gonna move them to records 2.5. Now notice one. The data got transferred, but the
status properties didn't remain the same because those new status properties
did not exist in this new version. Second, the artist property
is currently empty. But let's see what happens. When I migrate from artist 1.0 to
Artist 2.0, I'm gonna do the same thing. I'm going to select all of the artists. I'm going to migrate them
and move to artists 2.0. Now the artists now exist in Artist
2.0, the artist property column here. That's Artist 2.0. But notice those values
were not transferred over when I made that migration. I'll scroll back up here to show you. That's why it's important. For the entire system to be
duplicated together at once. Because if you try to do this in parts,
even if you map each relationship back exactly the way that it was, the
integrity of the connection between those relationships will not remain intact. Okay, so you want to make sure that
the entire system is duplicated all at once when you're doing
these kinds of data transfer. Awesome. So I just went ahead and I undid that move
and I'm just gonna reset it back to having all of the data back into version 2.0. So moving everything back from
1.0 to 2.0, just to show you. That it's flexible and dynamic, and I
can do that and I'll move the data from the artist's database into Artist 2.0. So now you'll see the relationships
remain intact, the relationships remain intact, and the same applies
for any other database configuration. Here I have version 1.0 and I'll
transfer that data over to Albums 2.0. And you'll see here the records,
the ones that were related, maintained that integrity. Okay.
Maintained the integrity. So that is getting your data transferred
from one version of a system into that new version of a system. Lastly, what I will say in regards
to templates, if you have brand new templates that you've configured that
you want transferred into that new database, what you'll have to do,
unfortunately, is go into that database, copy all of the elements inside of it. I highlighted them all by hitting command
A and then command C to copy, go over to that brand new database, add in that
new template, and then drop in those elements by hitting command V to paste. Okay. Now, for the property configurations
of that template, you will have to go back in and reset those as well. Okay? So that's just par for course, but
once you have this template set up, you're all good to go to start
using it for your newer project. And with that, I hope I've
provided you all with a ton of value here in this video. Today we discussed database upgrades
and migrations, so moving from existing template systems and migrating
that data over into new versions of those templates and systems. I hope this allows you all to take
advantage of some of these newer features that are rolling out for Notion and all
of the incredible templates that will have a lot of these new features implemented. All right, so that's all for now. Till next time, peace and blessings. Peace and blessing.
