When migrating to our theme + plugin setup, we often get asked about how it's done in a single large project. There's often multiple separate projects that actually need to be done, and unless hiring a custom developer for $5,000 - $20,000, this is going to have to be broken into multiple smaller projects.
We only provide assistance with steps #3 (theme) and #4 (plugin).
Before anything can be done, you need to be on a WordPress site.
We don't offer migrations from Wix or Squarespace (or other platforms) to WordPress. There are tons of issues that arise from this and it needs to be handled by an expert.
We have not vetted this company, but wpexperts.io has platform conversion services listed.
Different hosting companies have different basic configurations, services and support levels. We recommend either BigScoots and Agathon.
This must be a self-hosted WordPress installation (eg. not WordPress.com)
You must remove or migrate any content in pagebuilders (such as Divi, Thrive, Beaverbuilder) before tackling a theme migration. See why we don't support pagebuilders.
Note: staging sites
We recommend performing the theme and Feast Plugin setup on a staging site.
It's important not to work on your live site after creating the staging site. This is because the staging site will entirely replace the live site when it goes back live.
A theme+plugin setup is a big project in itself - do not complicate this with customizations, editing categories or removing tags. Wait a minimum 4 weeks before performing any other major updates after a theme update.
The majority of themes (even our own older versions) contains code and customizations that are outdated and doing more harm than good. The best thing you can do is simply trash the old setup and start with a fresh install.
Access to all our themes are included with the Feast Plugin, which is what we recommend purchasing.
In the past, the theme was this "all in one" setup that included both styling and functionality. Now, themes aren't meant for functionality and are used only for styling.
The entire site setup is done through the Feast Plugin.
NOTE: some outdated themes have built-in recipe cards - you must export or convert these recipes cards to a modern equivalent (Create, Tasty Recipes or WP Recipe Maker) before migrating.
4. Feast Plugin
With the change to the block editor and eventually the "full site editor", we've had to rewrite how the sites were built to adapt to this new setup. While doing this, we've implemented more modern best practices for SEO and accessibility and created an overall better user experience.
Make sure to check for, and re-add any analytics traffic code that may have been tied to the old theme.
If you have ads, be sure to reach out to your ad network to let them know you've made a theme change/update so that they can make any necessary adjustments to their ad positioning and targeting.
Our themes and plugin are designed to be compliant with pagespeed and SEO as much as possible, but this ultimately falls on external plugins and services.
There simply is no single solution to this, and any theme or framework claiming otherwise is lying (intentionally, or by omission).
The bare minimum involves installing and properly configuring WP Rocket.
However, the key to attaining great pagespeed is removing poorly performing plugins and scripts. You must perform a plugin audit and pagespeed audit and remove any services and scripts that aren't designed for pagespeed (which is most of them).
We can recommend imarkinterative.com's pagespeed services.
The only goal of a recipe page is to provide a bunch of images + text to the reader so that they can make a recipe. Anything outside of this will compromise that experience and the penalty it introduces has to be justified.
We don't offer customization services.
Once the theme and plugin have been setup and installed, you can begin performing customizations such as tweaking colors, fonts and styling. This can be done with CSS, or by hiring a designer.
In the past, a limited number of configurations could be done through the customizer but this was always inadequate and often lead to accessibility issues. The customizer was never more than an inadequate toy, and as such, we've dropped it from our toolset.
In general, we don't recommend making customizations, see: why you shouldn't make customizations.
Any customizations, even seemingly minor things, requires a large volume of back and forth emails with designers to guide design choices, ensure color contrast compliance, avoid outdated plugins, and prevent CLS. These customizations must then be revisited and maintained every year to ensure continued compliance. This is simply not feasible at scale.
Designers who are experienced with SEO, accessibility, pagespeed, and changes coming in the WordPress are rare, and expensive. Any designers we know are currently backlogged 6-12 months, and have minimum project sizes in the thousands.
That doesn't mean that you can't use woocommerce or run ecommerce functionality, it just means that our themes don't have built-in functionality and we won't offer any support for troubleshooting pagespeed or styling conflicts that arise from it.
Generally, you need to hire a private developer at least on contract ($2000+/month) to support and troubleshoot ecommerce functionality. Unless you're making over $2000/month in profit from ecommerce sales, this is simply not worth it in 99% of cases.
Instead, you should use one of the dozens of third-party services specifically set up to manage ebook/digital product sales, such as GumRoad.
Q: Will my URLS change?
A: Themes shouldn't modify URLs, so your URLs shouldn't change when changing themes.
However, we've seen at least one theme where certain posts were forced under a "recipes" slug. This is a misconfiguration on that specific theme and not something we're able to provide support for.
Q: What about my Pinterest/Google site verification?
A: This will depend on how they were implemented. If they were done in the "Customizer" rather than the code snippets plugin, they may be lost during an update.
You'll need to track down where this was done, and preferably re-implement it in the Code Snippets plugin (which isn't modified during a theme update).