One of the features that was released in Sitecore 10.1 was the use of Item As Resource (IAR) files to store the default items in an out of the box installation. From Sitecore 10.2 onwards this extended beyond just the items on the base installs, many Sitecore modules also started to use IAR files as well. The CLI tooling was also updated to allow users and community members generate their own IAR files for their custom modules and solutions. We have been using this feature extensively at Konabos since it's launch, it really makes the Continuous Integration and Deployment (CI/CD) process much simpler and faster.

If you’re unsure of where these files are, the out of the box check the /App_Data/items folder. There you will find folders for each database, and within those the IAR files.

In case you are unsure of how the process now works, instead of items being stored in the SQL databases (core, master, web) these items are now stored in the IAR files. A new item provider now loads the items first from the IAR files, then loads items from the database and then "layers" them on top to generate the final item hierarchy.

In the past couple of years, we have also been working on a large number of upgrades for customers. We all know that traditionally Sitecore upgrades can be a time consuming and complex process. The use of IAR is a really great step towards easing the overhead required for future upgrades, which we previously wrote about in our article about What's new in Sitecore 10.1. Since the base items for an install now sit in the IAR file rather than in the SQL databases, in theory and upgrade should just be a case of replacing the existing .dat file with the new .dat file, restart the system and the items at least are up to the latest version.

During many of these upgrades, we have also been making the "side-grade" - shifting across customers who previously had Sitecore XP installed but were not really making use of the full set of features on that platform, e.g. Analytics, Personalisation, A/B Testing, Email Campaign Manager etc. Many of the customers had already taken a composable approach to their MarTech stack, and their teams were already using different systems to fulfil the needs of their business.

This got me thinking though… given that all the base Sitecore items are now in IAR files, the only items being stored in the databases is just item data that the users are adding - their content, their forms, their media, their settings items, their templates/layouts/renderings (assuming you did not create IAT files for these yourself). And if that is the case, could I not just take a set of Sitecore databases (core, master, web) from and XM installation, and at future date just attach these to an Sitecore XP installation? Given the base XP items are in the IAR files, adding my databases should just layer my content items on top on the XP install right?

Let's dig into the default installation files and investigate.

As to be expected, the installation file size for XP is a lot larger than XM, esp given the many additional services required for XP.

You can also see that the IAR files for the base install of XP is larger than XM, which is again to be expected since there are many more items, layouts, renderings, application definitions etc in XP compared to XM.

Here is where it differs and this caught me a little by surprise. I thought all the default ootb items were in the IAR files, so why are the database sizes for the installs different? I was expecting them to be the same for core, master and web between XP and XM, you can see that Experience Forms and the Sessions databases are exactly the same.

Let's open these databases in SQL Server and run a report to check where the differences are.

We can see that in the Core databases the difference is in the Security Roles and the Links table, which makes sense since it due to the Analytics and Marketing related roles, as well as the additional features and applications present in XP meaning a larger Links table. (Even though the base items themselves are in IAR files, the Links DB still sits in the SQL database).

For the Master database (and the Web) we can see that again the Links table is larger as to be expected, but there is a difference of 10 vs 1 entry only in the Items table between XP and XM. By running a Select query on this table we can see the following records are returned.

When you head into our XP instance and we search for the items with these guids they relate to the following items:

{7356F179-B8D2-4091-AC17-D65F02E4416D} : /sitecore/system/Settings/Email/Instance Tasks/Content Management Primary/Reset Failed Automated Messages

{7317161B-C430-4FA5-87CF-5CC4D46995F5} : /sitecore/system/Settings/Email/Instance Tasks/Content Management Primary/Message Statistics/Missing

{BF03CB73-1F03-4034-9418-21214A2AA1FE} : /sitecore/system/Settings/Email/Instance Tasks/Content Management Primary/Message Statistics/Older

{238E4FD9-C8C6-499A-A0A1-5259B1B24D3A} : /sitecore/system/Settings/Email/Instance Tasks/Content Management Primary/Message Statistics/Recent

{A6599689-3616-4938-A5BB-9EC65480D2F3} : /sitecore/system/Settings/Email/Instance Tasks/Content Management Primary/Message Statistics/Today

{44428794-05A4-4BE6-90D6-7D0BF128D17E} : /sitecore/system/Tasks/Schedules/Content Testing/Rebuild Suggested Tests Index

{9955F85F-9EE1-4469-BD70-5422AF976461} : /sitecore/system/Tasks/Schedules/Content Testing/Suspend Corrupted Tests

{5A507736-A0A2-46F7-BE59-7324E584796E} : /sitecore/system/Tasks/Schedules/Content Testing/Try Finish Test

{3D8F6795-1C4E-462D-8A81-BE27B1AEC5BD} : /sitecore/system/Tasks/Schedules/Forms/FileStorageCleanup

This makes sense. These are "configuration" items, and the schedule may not be something you wish to either keep, or may wish to update anyway. Items in the IAR files are "read only", meaning you cannot delete them. You can override them, but that causes the override item values to be inserted in the SQL database, which in turn causes the layering of the items we spoke about earlier. By having the item definitions in the SQL database to begin with, it allows you to actually delete these items if you wish.

Why is this important? 

That's great, but why is this all important, why was I interested in this?

The majority of the time we hear from customers that they purchased and implemented Sitecore with the hopes and dreams of creating a fully personalised experience for their users, but for whatever reason they never quite manage to get to the right level of digital maturity in order to fully make benefit of the features. But they still like to keep that option open that in the future they may still want that… and if they are running an XP license they may not want to pay for additional services to go fully composable. 

Having the option available to be able to switch is a very powerful reassurance. And the way the Sitecore platform is now built using IAR files allows customers a lot of freedom to switch and move from Sitecore XM to XP, or vice versa, without a heavy clean up of the base items in the databases. An upgrade is the perfect time to make the switch from Sitecore XP to XM if you have not been using those DXP features, and especially so for the customers finally upgrading from the pre-9.0 installations which had a much lighter footprint and required less services to run that the post-9.0 installations. This helps keep infrastructure costs down and more simple to manage.

So can you take your databases from a Sitecore XM installation and just connect them to a Sitecore XP installation?

Yes you can, just there may be some "missing" items from your initial database - these are fairly minor set of items but you should migrate these across (using Sitecore packages or SQL scripts) if they are useful for you. But Sitecore's move to using Item As Resource files for the base installation now makes switching between the 2 versions of their All-in-One DXP much simpler and faster than any previous release.

Hope this was helpful and interesting. If you require any help with upgrades, or "side-grades", then please get in touch!