Sentrifugo is a self-hosted PHP HRMS built on the Zend Framework, and it stores several hard references to its own URL and filesystem location. When you move the application to a new domain, clone it into a staging subdomain, or restore a backup into a different document root, those stored references no longer match reality. The symptoms are predictable: login redirects to the old hostname, uploaded documents and profile photos return 404s, CSS and JavaScript fail to load because asset URLs point at the previous domain, and background actions silently break. None of this indicates corruption. Sentrifugo simply trusts the values written into its configuration file and database during the original installation, and a migration invalidates them.

On a Hostiso Managed Cloud account you handle the entire relocation from inside cPanel Jupiter or DirectAdmin Evolution using File Manager, phpMyAdmin, and standard PHP configuration files. There is no need for shell access, and every step below stays inside the unprivileged hosting user's scope.

Moving the files and database to the new location

Start by taking a clean copy of both halves of the installation. In cPanel, open File Manager, navigate to the current Sentrifugo directory (commonly public_html or a subfolder such as public_html/hrms), select all files, and use Compress to build a single zip archive. Download that archive. Then export the database: open phpMyAdmin, select the Sentrifugo schema, choose the Export tab, keep the Quick method with SQL format, and save the .sql file locally. Keeping both artifacts before you touch anything gives you a rollback point.

On the destination, decide the new document root first. If the target domain is an addon domain or subdomain, cPanel assigns it a folder like public_html/newdomain.com; DirectAdmin uses domains/newdomain.com/public_html. Upload the zip into that folder through File Manager and extract it there. Confirm that the extracted files sit at the web root you expect and not one level too deep — a stray parent folder is the most common cause of a post-migration blank page.

Create a fresh database and database user on the destination account. In cPanel use MySQL Databases; in DirectAdmin use MySQL Management. Assign the user to the database with All Privileges, and record the exact database name, username, and password — the shared-hosting prefix (for example cpuser_) usually differs from the source account, so these values will not match the old ones. Import your .sql dump into the new database through the phpMyAdmin Import tab. If the dump is large and the import times out, split it or raise limits temporarily via .user.ini as described later.

Updating Sentrifugo configuration and database credentials

Sentrifugo keeps its database connection details in application/config/config.ini relative to the install root. Open that file in File Manager with Edit and update the connection block so it points at the new database you just created. The relevant keys look like this:

db.type = mysql
db.host = localhost
db.dbname = cpuser_sentrifugo
db.username = cpuser_sentapp
db.password = your_new_password
db.charset = utf8

Use localhost as the host on Hostiso shared servers unless you were explicitly given a remote database host. Save the file, then reload the site. A connection error at this stage almost always means a typo in the database name or a user that was not assigned to the schema — recheck the mapping in MySQL Databases.

Sentrifugo also records the base URL of the application inside its database rather than only in a file. That value drives redirects, generated links, and asset paths. In phpMyAdmin, run a targeted search across the settings tables before changing anything, so you know exactly where the old domain lives:

SELECT * FROM app_config
WHERE config_value LIKE '%olddomain.com%';

Depending on your Sentrifugo version the base URL and any absolute path references may sit in app_config, in a general settings table, or in email-template rows. Update the matching rows with an explicit statement so you control precisely what changes:

UPDATE app_config
SET config_value = 'https://newdomain.com'
WHERE config_value = 'https://olddomain.com';

Repeat the search for any stored absolute filesystem path (the old /home/olduser/public_html/... style string) that may appear in document-management rows, and correct those to the new account's home path. Editing individual rows through the phpMyAdmin table browser is equally valid if you prefer a visual check over raw SQL. Always confirm you are operating on the correct schema — never run global server-level statements.

Fixing paths, permissions, .htaccess, and PHP settings

Sentrifugo writes uploads and generated files into directories such as public/uploads and public/temp. After extraction these folders must be writable by the web server. In File Manager, right-click each and use Change Permissions; 755 for directories and 644 for files is the safe baseline on CloudLinux, and Sentrifugo's writable folders work fine at 755 because PHP runs as your account user under LiteSpeed. Avoid 777 — it is unnecessary here and often rejected by the server's security policies.

If the application lives in a subfolder or you changed the document root, review the .htaccess file at the web root. Sentrifugo's rewrite base can drift when the folder depth changes. A working rule set for a root install reads:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]

For an install inside public_html/hrms, change the base to RewriteBase /hrms/ so front-controller routing resolves correctly. If you are also moving from HTTP to HTTPS on the new domain, add a canonical redirect near the top of the file so old bookmarks and stored links land cleanly:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

Match the PHP version to what your source used. Use cPanel MultiPHP Manager or DirectAdmin's PHP selector to set the domain to the same major version Sentrifugo ran on originally, then enable required extensions (gd, mysqli, mbstring) in the PHP Selector extensions panel. If a large database import or a bulk document restore stalls, raise limits locally by placing a .user.ini at the web root:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120

LiteSpeed reads .user.ini changes after a short delay, so wait a minute or two before retesting. Finally, clear Sentrifugo's caches. The Zend framework layer caches metadata under the writable temp and cache directories inside data or public/temp; deleting the contents of those cache folders (never the folders themselves) forces a rebuild with the corrected URL and paths. When something still fails, check the local error_log that appears in the affected directory through File Manager — it names the exact file, permission, or database issue rather than leaving you to guess. Work through those log lines one at a time and the migration settles quickly.