This guide walks you through migrating your existing documentation from the current Dev Portal to the new Dev Portal powered by Zudoku. Follow these steps sequentially for a smooth transition.
Before you begin
It's important to note that this migration is to a completely new developer portal. As such, there could be things that are different or don't map exactly to the old developer portal. This new developer portal is more powerful and flexible, but it may require some adjustments to your existing content and configuration.
A few things to keep in mind before starting the migration:
Separate domain for Dev Portal
New Dev Portals run on their own dedicated domain instead of a /docs path
under your API. You must create a redirect route on /docs to maintain existing
links. You can use the
dev portal handler to
achieve this.
Builder plans have been automatically upgraded to include two custom domains instead of one. This allows you to have a custom domain for both your API and your developer portal.
Authentication changes
Not all authentication providers from the old Dev Portal are supported in the new Developer Portal. The previous "external" provider isn't supported. If you were using that provider, you will need to switch to a supported provider such as Auth0 or implement a custom authentication solution.
Other considerations
- Theming: Custom CSS from the old Dev Portal isn't directly supported. You will need to reapply any custom styles using the new theming options in Zudoku.
- Navigation: Navigation in the new developer portal is much more flexible, but this does mean you will likely need to update your navigation structure.
- Dark Mode: The new Dev Portal has built-in support for dark mode, which wasn't available in the old portal. You may want to use a different logo for dark mode.
Test in a preview environment
Don't perform the migration directly on your production environment. Instead, create a preview environment to test the migration. This allows you to verify that everything works as expected before making the changes live.
Things to test in the preview environment:
- Navigation between pages
- Authentication flows
- API reference rendering
- API Playground functionality
- Custom theming and styles
Migration options
There are three ways to migration your existing Dev Portal to the new version. Choose the one that best fits your needs:
- Migrate in the portal (for simple setups)
- Quick migration with CLI (for most projects)
- Manual migration process (for full control)
Migrate in the portal
If you have a simple Dev Portal setup and prefer to migrate directly in the
Zuplo Portal, you can use the built-in migration tool by opening the
config/dev-portal.json file in the Zuplo Portal and clicking the Migrate to
Zudoku button at the top of the editor. This will automatically create the
necessary files and move your existing configuration and markdown files to the
new format.
Quick migration with CLI
For most projects, you can use the Zuplo CLI to automate the migration process:
Code
This command will automatically:
- Create the required directory structure
- Generate necessary configuration files
- Migrate your existing dev portal configuration
- Move markdown files to the correct location
See the Source Commands documentation for more details and options.
If you prefer to understand each step or need more control over the migration process, continue with the manual migration steps below.
Manual migration process
-
Prepare Your Environment
Clone your existing Zuplo project locally. We recommend trying this in a branch and deploying to a preview environment first.
CodeCurrently, this migration must be done locally. It cannot be done in the Zuplo Portal.
-
Create Directory Structure
Set up your new directory structure by creating the following files and folders:
- Create
docs/zudoku.config.tsas an empty file, the contents will be added later. - Create
docs/package.jsonas an empty file, the contents will be added later. - Create
docs/tsconfig.jsonas an empty file, the contents will be added later. - Create a directory
docs/pagesfor your markdown files - Create a directory
docs/publicfor images and other static assets
Once these files are created your directory structure should look like this. Note, that the old dev portal files are still in place. You will delete them later.
Code - Create
-
Update Typescript Configuration File
If you haven't already, create a
tsconfig.jsonfile in thedocsfolder and update the file with the following content.docs/tsconfig.json -
Update
package.jsonFileIf you haven't already, create a
package.jsonfile in thedocsfolder and update the file with the following content.docs/package.json -
Update Root Package.json
Add the
workspacesconfiguration to your rootpackage.jsonfile. Optionally, add a new scriptdocsto run the dev portal.package.json -
Migrate Dev Portal Configuration
If you haven't already done so, create a new
zudoku.config.tsfile in thedocsdirectory to replace your existingdev-portal.json.Here's how several fields map from old to new format. See the configuration documentation for a complete list of options.
Old ( dev-portal.json)New ( zudoku.config.ts)pageTitlesite.titlefaviconUrlmetadata.faviconenableAuthenticationImplied by presence of authenticationpropertyauthentication.providerauthentication.typeauthentication.authorityProvider-specific properties (from sidebar.json) navigationarrayExample configuration:
docs/zudoku.config.tsEnvironment variables are now referenced using
process.envinstead of$env(). -
Migrate Sidebar Configuration
Move your sidebar configuration from
sidebar.jsonto thenavigationarray inzudoku.config.ts:Old format (
sidebar.json):CodeNew format (in
zudoku.config.ts):Code -
Move Markdown Files
Move your markdown files to the
docs/pagesdirectory. The front matter format remains largely the same:Code -
Set Up Images and Assets
Create a
docs/publicdirectory for your images and other static assets. See the documenation for more information on how to use static files in the new dev portal. -
Install Dependencies
Run
npm installfrom your project root to install all dependencies for both your API and documentation. -
Test Locally
Start the dev portal locally with
npm run docsand verify that:- All pages load correctly
- Authentication works (if using it)
- All links between pages work
- API reference section loads your OpenAPI definitions
- Images and assets display properly
-
Delete Legacy Files
After confirming everything works, delete these files:
/config/dev-portal.json/docs/sidebar.json/docs/theme.css
It is critical that you delete the
config/dev-portal.jsonfile after completing the migration. If that file is not deleted, the Zuplo build system will use the legacy dev portal. -
Deploy and Verify
Deploy your changes by either pushing to a git branch or by running
npx zuplo deploy. After the deployment has completed, perform these final checks:- Test all site navigation paths
- Verify authentication flows work correctly
- Check API reference documentation renders
- Test across different browsers and devices
- Verify custom styling and theming is applied correctly
Theming
For instructions on theming the dev portal, see Colors & Theme and Fonts.
Redirect legacy URLs
The previous Dev Portal was hosted on a path on the same domains your Zuplo API
(i.e. https://api.example.com/docs). The new Dev Portal is hosted on its own
domain and can have its own custom domain (i.e. https://docs.example.com).
Learn more about setting up custom domains in the
Custom Domains documentation.
If you were using the previous Dev Portal, you can redirect all requests from the legacy path to the new domain using a Zuplo route. This allows you to maintain backwards compatibility for users who may have bookmarked or linked to the old Dev Portal URL.
Setup Instructions
-
Create a New Routes File: In your Zuplo project, create a new OpenAPI file called
legacy.oas.json(or any name you prefer). -
Add a Route: Inside this file, add a route that matches the legacy path and redirects to the new Dev Portal domain. You must set the path to the path used by the previous Dev Portal, such as
/docs(.*). It's important not to make the route/docs(.*)not/docs/(.*)in order to also match the root path/docs.For example:
Code
After you redeploy you Zuplo project, whenever the user navigates to the legacy developer portal paths, they will be redirected to the new Dev Portal domain.
The legacyDevPortalHandler also supports a proxy mode if you prefer to keep
your developer portal on the same domain under a path. This isn't recommended
for performance and usability reasons, but is available if needed. To use proxy
mode, change the mode option to proxy instead of redirect.
Additional redirects
Your new developer portal may also change other paths. To create redirects for
specific docs or other path in your new Dev Portal, we recommend using the
redirects configuration in the zudoku.config.ts file. This allows you to
specify multiple redirects easily. For more information, see the
Redirects section in the configuration docs
Troubleshooting
If you encounter issues during migration, check these common problems:
- Missing dependencies: Ensure you've run
npm installfrom the project root. - Authentication issues: Verify your environment variables are correctly set and authentication is properly configured.
- Sidebar not showing: Check your sidebar configuration in
zudoku.config.tsand make sure file IDs match your markdown files. - Images not loading: Confirm image paths have been updated to point to the new location.
- Environment variables not working: Use
process.env.VARIABLE_NAMEinstead of$env(VARIABLE_NAME).