Quick answer
Store custom changes in a supported extension point rather than files an update replaces. A child theme can hold certain presentation changes; site functionality may belong in a plugin or another documented location.
Before you begin
Identify the active parent and child themes and where custom code currently lives. Back up the site and use staging before changing how customizations load.
What to do
- List customizations and their purpose. Separate presentation, business logic, forms, integrations, and content so each has an appropriate home.
- Check the theme documentation for supported hooks, templates, and controls. Existing settings may meet the need without additional code.
- If appropriate, create or update a child theme using the parent theme requirements. Do not copy the entire parent theme to change one template.
- Move approved customizations in a controlled way and retain the original for rollback. Check template inheritance, dependencies, and loading order.
- Test affected pages and editing controls. Review a parent theme update on staging to confirm the customization still works.
How to check the result
After the update, custom changes should remain identifiable and documented. Compare affected pages against the baseline and check for duplicate styles or functions loaded from old and new locations.
If you need help
A child theme does not guarantee compatibility with future architecture changes. Database-stored builder settings and outdated template overrides need their own review. Ask for a change inventory if nobody knows where the current customizations were added.
Related help
- Update a WordPress plugin with a clear rollback plan
- Create a recoverable checkpoint before an AI website deployment
- Choose a selective rollback instead of restoring everything
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
