Several previous articles offered nearly identical installation instructions for older CMS packages, including Subrion, PHP-Fusion, Zikula, Plikli, PyroCMS, Geeklog, ImpressPages, PopojiCMS, Croogo, Anchor, liveSite, Saurus and Typesetter. This guide replaces those old installation recipes with a practical evaluation and migration process.
IN THIS ARTICLE
01 Plan and perform the migration
- Identify the actual application version, custom modules, user roles, data types, forms, uploads and integrations. Confirm whether a current supported upgrade path exists before deciding to replace the platform.
- Create complete database and file backups and verify a separate restore. Protect configuration secrets and keep the original site unchanged while evaluating alternatives.
- Choose a current platform that supports the required business functions. Map each old data type to its destination fields, including dates, authors, relationships and private content.
- Build a test migration. Compare content counts and representative records, then test roles, forms, email, media and integrations using realistic non-sensitive samples.
- Schedule the final content freeze, move the latest data using the verified process, create URL redirects and retain a recoverable source copy until the new site passes acceptance checks.
02 Verify the complete result
Test business outcomes, not only the home page. A directory, listing system or membership site may have permissions and data relationships that a simple page export does not preserve.
03 Resolve an unsupported migration path
An old package remaining in a public installer catalogue does not establish that it has a maintained security update path. Check the project and dependencies directly. If you keep an older application temporarily, agree on a concrete isolation, backup and replacement plan with the site maintainer.
04 Example: map content before replacing an older CMS
Use a rehearsal spreadsheet with one row per content item or record. The following values are examples, not names your database must contain.
| Source item | Destination decision | Acceptance check |
|---|---|---|
| /news.php?id=42 | /news/company-update | Title, date, author, image and permanent redirect match. |
| Members-only handbook | Restricted document area | Signed-out visitors cannot read the page or download the file. |
| Customer enquiry form | New supported form component | Required fields, delivery recipient and spam controls work. |
Compare item counts and sample the migrated records. A homepage that looks right is insufficient if old links, private downloads or customer messages are lost.
Common questions
Will every old feature transfer automatically?
No. Importers support particular source versions and data types. Identify unsupported fields, accounts and extensions before the final move and agree how each will be replaced or retained.
Can you help with the hosting side?
Request a migration review with the source application, size and required functions. Hosting migration and application conversion are different scopes; support can confirm the available service and any work that needs a developer.