Drupal to Sitecore SXA
One of my recent projects was a full site lift and shift from Drupal to Sitecore 10.2 and SXA. The goal was to make the new frontend Sitecore site look exactly like the old Drupal site. We did fix a few accessibility issues on the existing site as we went, but we did not change any of the design or ux.
We had a pretty tight deadline, a large number of components to build, and a large number of pages to migrate. I was concerned about how to accomplish the project in the given timeline and make it look exactly like the old site. SXA uses bootstrap by default (among several other ui frameworks available). Bootstrap has its own breakpoints, containers, grid classes, paddings and margins, and components. The Drupal site used a custom theme with custom breakpoints, custom grid classes, custom paddings and margins.
Mapping Out a Plan
How would we build these components in bootstrap and make the layout match? How would we test the responsive layout in tablet and mobile? How would we capture all the active and hover states? How would we untangle the existing css and migrate style to the new sxa and bootstrap classes? How would we know we didn’t miss anything?
So how did we deliver the project? We didn’t use bootstrap. We created a custom theme that used a custom grid (which was really no grid). We imported the scss and javascript directly from Drupal. We copied the live html structure and classes to create the scriban renderings. We created new datasources that mapped into our scriban renderings. We saved a TON of time and bugs over converting the site to bootstrap. From a site migration point of view, the process worked exactly as I expected!
Let’s take a deeper dive into the lift and shift process we used. In part 1, we’ll show the theme, grid setup and the base sxa component. Following in part 2, we’ll create some rendering variants and the related datasources. In part 3, Maria Xavier talks about converting the css and Drupal-specific javascript. In part 4, we’ll show how we tracked the list of pages to migrate and the overall progress. In part 5, we’ll see how the qa team validated the new site by comparing to the old site and tracked existing bugs on the site that were out of scope to fix during this process.
Do you need to migrate your site? Reach out to see how Perficient can help you migrate your site.
