• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Resolved Plesk Migrator: Subscribers, Service Plans and Customers not properly transferred

Server operating system version
Ubuntu 22.04.2 LTS
Plesk version and microupdate number
18.0.52 Update #2
Hi,

using plesk migration tool i get green checkmarks on all of 21 (sub)domains i want to migrate from current plesk linux to plesk linux, moving from Ubuntu 18.04 to 22.04.
However, checking customers, subscribers and service plans, mostly is not migrated.
After first try of migration, customers are not present, subscriber for all domains got "Administrator" and service plans are set to the default setting.
Re-syncing partially fixes some issues, but also throws errors regarding on creation of "auxiliary users" which havent been there before. I don't prefer to do that since i'll have to fix new problems.

I found a warning message when having a look at the debug log, which i assume is the explanation, but i can't figure the solution:

Code:
2023-05-16 11:42:29    Info   

START: Deploy hosting
2023-05-16 11:42:29    Info   

START: Restore logins of system users
2023-05-16 11:42:30    Info   

Import backup dumps to target panel's repository
2023-05-16 11:42:30    Debug   
Remove backup file migra_info_2305161141.xml from target Plesk
2023-05-16 11:42:30    Debug   
Delete dump request XML: <?xml version="1.0"?>
<delete-dump-query>
    <dump-specification>
        <dumps-storage-credentials storage-type="local">
            <root-dir>/var/lib/psa/dumps</root-dir>
            <file-name/>
        </dumps-storage-credentials>
        <name-of-info-xml-file>migra_info_2305161141.xml</name-of-info-xml-file>
    </dump-specification>
    <object-specification type="server" guid="00000000-0000-0000-0000-000000000000"/>
</delete-dump-query>
    
2023-05-16 11:42:30    Debug   

Execute command on the local server: /opt/psa/admin/bin/pmmcli --delete-dump
2023-05-16 11:42:31    Debug   
Upload backup dump '/usr/local/psa/var/modules/panel-migrator/sessions/20230513185546/plesk.backup.source.converted.tar' to target server
2023-05-16 11:42:31    Debug   

Import backup dump to target panel's repository
2023-05-16 11:42:31    Debug   
Fixing dump to pass validation rules for Plesk version 18.0.27 and higher
2023-05-16 11:42:31    Debug   
Import backup to target panel PMM repository.
2023-05-16 11:42:31    Debug   
Import dump request XML: <?xml version="1.0"?>
<src-dst-files-specification guid="00000000-0000-0000-0000-000000000000" type="server">
    <src>
        <dumps-storage-credentials storage-type="file">
            <root-dir>/usr/local/psa/var/modules/panel-migrator/sessions/20230513185546/target-server</root-dir>
            <file-name>plesk.backup</file-name>
        </dumps-storage-credentials>
    </src>
    <dst>
        <dumps-storage-credentials storage-type="local">
            <root-dir>/var/lib/psa/dumps</root-dir>
            <ignore-backup-sign>true</ignore-backup-sign>
        </dumps-storage-credentials>
    </dst>
</src-dst-files-specification>
    
2023-05-16 11:42:31    Debug   

Execute command on the local server: /opt/psa/admin/bin/pmmcli --import-file-as-dump
2023-05-16 11:42:36    Debug   
Command execution results:
stdout: <?xml version="1.0" encoding="UTF-8"?>
<response>
    <errcode>152</errcode>
    <errmsg>The file you are trying to upload is not a valid backup file</errmsg>
    <data>
        <dump name="migra_info_2305161141.xml" fullname="migra_info_2305161141.xml" isFull="true" creation-date="2305161141" description="" size="0" owner-guid="" owner-type="" verification-string="$AES-128-CBC$ON2vCxIzQ0knhCEdB/2Ofw==$4/2CD5fEiwXVpT2c0bsVZ68ZoS9jSc7PPKEf3rcINmE=" encryption-type="panel-key" dump-version="18.0.52" dump-original-version="18.0.52" dump-format="panel" content-included="false">
            <dump-status dump-status="OK" backup-process-status="">
                <details>
                    <message>migra_info_2305161141.xml: </message>
                </details>
            </dump-status>
            <dump-status dump-status="SIGN-ERROR" backup-process-status="">
                <details>
                    <message>migra_info_2305161141.xml: </message>
                </details>
            </dump-status>
            <dump-status dump-status="WRONG-FORMAT" backup-process-status="">
                <details>
                    <message>migra_info_2305161141.xml:
Line 251 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.

Line 279 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.

Line 307 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
</message>
                </details>
            </dump-status>
            <storages>
                <storage>local</storage>
            </storages>
        </dump>
    </data>
</response>

stderr:
exit code: 0
2023-05-16 11:42:36    Warning   
Failed to import Plesk configuration dump: backup file is not valid or corrupted.
Migration will try to continue, but there could be issues when restoring hosting settings.
2023-05-16 11:42:36    Debug   
Imported backup id reported by pmmcli is '2305161141'
2023-05-16 11:42:36    Debug   

Create mapping of domain name to backup XML file name
2023-05-16 11:42:36    Info   
FINISH: Deploy hosting

I'd be thankful for any kind of help.
 
Have you checked that on the source system there is enough free disk space so that all data can be collected and archived before being transferred to the new server?
 
Have you checked that on the source system there is enough free disk space so that all data can be collected and archived before being transferred to the new server?
How much free space will be needed for this particular operation in the migration process?
On my source system, "df -m" says that 72% of /dev/sda1 with a partition of 246GB in size is being used.
The Email files are mounted from an NFS share to /var/qmail/mailnames which has 81% of 252GB used.
Expanding any volume won't be a problem, but i'd need an estimated size of expansion if this would be even neccesary in my case.
 
It is difficult to assess the necessary disk space, because it depends on the type of data migrated and where the temporary dumps directory is located. I think that 28 % free space is not enough, but this is not for sure. I am not so sure whether NFS is supported for migrations at all.

First, please let's look into the migration log on the target server. You find it in /usr/local/psa/var/modules/panel-migrator/sessions/*. info.log and debug.log should explain the exact cause why the migration failed.
 
It is difficult to assess the necessary disk space, because it depends on the type of data migrated and where the temporary dumps directory is located. I think that 28 % free space is not enough, but this is not for sure. I am not so sure whether NFS is supported for migrations at all.

First, please let's look into the migration log on the target server. You find it in /usr/local/psa/var/modules/panel-migrator/sessions/*. info.log and debug.log should explain the exact cause why the migration failed.
Ok, so i loaded an earlier state of my fresh plesk installation by rolling back to a snapshot just before the migration.
I then expanded the storage on the source server to 2TB, so the volume use is now far below 30%.
The problem persists in just the exact same manner, even if only migrating a single domain.
Here's snippets from the log files at the location you mentioned, which basically state the exact same errors as i already pasted from the gui in my first post. Also, there's no other warnings or errors thrown to these logfiles, not a single script running that exits with a code other than '0'.

I've cut away the timestamps here, since the posting is not allowed to exceed 10k characters:

info.log
Code:
[INFO] START: Deploy hosting
[INFO] START: Restore logins of system users
[INFO] [*****.net] START: Restore logins of system users
[INFO] FINISH: Restore logins of system users
[INFO] Import backup dumps to target panel's repository
[WARNING] Failed to import Plesk configuration dump: backup file is not valid or corrupted. Migration will try to continue, but there could be issues when restoring hosting settings.
[INFO] FINISH: Deploy hosting

debug.log
Code:
root@plesk:/usr/local/psa/var/modules/panel-migrator/sessions/20230516182531/debug.log
D|MT|core.workflow.runner.by_subscription|||START: Save converted backup to file
D|MT|core.dump.file_adapters|||Closed an archive file
D|MT|core.dump.file_adapters|||Closed an archive file
D|MT|core.workflow.runner.by_subscription|||FINISH: Save converted backup to file
I|MT|core.workflow.runner.by_subscription|||FINISH: Restore logins of system users
I|MT|core.workflow.runner.by_subscription|||Import backup dumps to target panel's repository
D|MT|core.utils.pmm.pmmcli|||Remove backup file migra_info_2305161827.xml from target Plesk
D|MT|core.connections.plesk_server|||Backup dumps directory on target Plesk server: /var/lib/psa/dumps
D|MT|core.utils.pmm.pmmcli|||Delete dump request XML: <?xml version="1.0"?>
D|MT|core.utils.pmm.pmmcli|||<delete-dump-query>
D|MT|core.utils.pmm.pmmcli|||    <dump-specification>
D|MT|core.utils.pmm.pmmcli|||        <dumps-storage-credentials storage-type="local">
D|MT|core.utils.pmm.pmmcli|||            <root-dir>/var/lib/psa/dumps</root-dir>
D|MT|core.utils.pmm.pmmcli|||            <file-name/>
D|MT|core.utils.pmm.pmmcli|||        </dumps-storage-credentials>
D|MT|core.utils.pmm.pmmcli|||        <name-of-info-xml-file>migra_info_2305161827.xml</name-of-info-xml-file>
D|MT|core.utils.pmm.pmmcli|||    </dump-specification>
D|MT|core.utils.pmm.pmmcli|||    <object-specification type="server" guid="00000000-0000-0000-0000-000000000000"/>
D|MT|core.utils.pmm.pmmcli|||</delete-dump-query>
D|MT|core.utils.pmm.pmmcli|||
D|MT|core.runners.base|||Execute command on the local server: /opt/psa/admin/bin/pmmcli --delete-dump
D|MT|core.runners.base|||Command execution results:
D|MT|core.runners.base|||stdout: <?xml version="1.0" encoding="UTF-8"?>
D|MT|core.runners.base|||<response>
D|MT|core.runners.base|||    <errcode>0</errcode>
D|MT|core.runners.base|||    <errmsg></errmsg>
D|MT|core.runners.base|||</response>
D|MT|core.runners.base|||
D|MT|core.runners.base|||stderr:
D|MT|core.runners.base|||exit code: 0
D|MT|core.actions.hosting_settings.import_backups|||Upload backup dump '/usr/local/psa/var/modules/panel-migrator/sessions/20230516182531/plesk.backup.source.converted.tar' to target server
D|MT|core.actions.hosting_settings.import_backups|||Import backup dump to target panel's repository
D|MT|core.utils.restore_hosting_utils|||Fixing dump to pass validation rules for Plesk version 18.0.27 and higher
D|MT|core.utils.pmm.pmmcli|||Import backup to target panel PMM repository.
D|MT|core.utils.pmm.pmmcli|||Import dump request XML: <?xml version="1.0"?>
D|MT|core.utils.pmm.pmmcli|||<src-dst-files-specification guid="00000000-0000-0000-0000-000000000000" type="server">
D|MT|core.utils.pmm.pmmcli|||    <src>
D|MT|core.utils.pmm.pmmcli|||        <dumps-storage-credentials storage-type="file">
D|MT|core.utils.pmm.pmmcli|||            <root-dir>/usr/local/psa/var/modules/panel-migrator/sessions/20230516182531/target-server</root-dir>
D|MT|core.utils.pmm.pmmcli|||            <file-name>plesk.backup</file-name>
D|MT|core.utils.pmm.pmmcli|||        </dumps-storage-credentials>
D|MT|core.utils.pmm.pmmcli|||    </src>
D|MT|core.utils.pmm.pmmcli|||    <dst>
D|MT|core.utils.pmm.pmmcli|||        <dumps-storage-credentials storage-type="local">
D|MT|core.utils.pmm.pmmcli|||            <root-dir>/var/lib/psa/dumps</root-dir>
D|MT|core.utils.pmm.pmmcli|||            <ignore-backup-sign>true</ignore-backup-sign>
D|MT|core.utils.pmm.pmmcli|||        </dumps-storage-credentials>
D|MT|core.utils.pmm.pmmcli|||    </dst>
D|MT|core.utils.pmm.pmmcli|||</src-dst-files-specification>
D|MT|core.utils.pmm.pmmcli|||
D|MT|core.runners.base|||Execute command on the local server: /opt/psa/admin/bin/pmmcli --import-file-as-dump
D|MT|core.runners.base|||Command execution results:
D|MT|core.runners.base|||stdout: <?xml version="1.0" encoding="UTF-8"?>
D|MT|core.runners.base|||<response>
D|MT|core.runners.base|||    <errcode>152</errcode>
D|MT|core.runners.base|||    <errmsg>The file you are trying to upload is not a valid backup file</errmsg>
D|MT|core.runners.base|||    <data>
D|MT|core.runners.base|||        <dump name="migra_info_2305161827.xml" fullname="migra_info_2305161827.xml" isFull="true" creation-date="2305161827" description="" size="0" owner-guid="" owner-type="" verification-string="$AES-128-CBC$eFtq4ogQ+C16k09XorzRTg==$1c7Rstn0cuBkaS5d5kg8VkEMYO9RebjWOt0QgevZ4hM=" encryption-type="panel-key" dump-version="18.0.52" dump-original-version="18.0.52" dump-format="panel" content-included="false">
D|MT|core.runners.base|||            <dump-status dump-status="OK" backup-process-status="">
D|MT|core.runners.base|||                <details>
D|MT|core.runners.base|||                    <message>migra_info_2305161827.xml: </message>
D|MT|core.runners.base|||                </details>
D|MT|core.runners.base|||            </dump-status>
D|MT|core.runners.base|||            <dump-status dump-status="SIGN-ERROR" backup-process-status="">
D|MT|core.runners.base|||                <details>
D|MT|core.runners.base|||                    <message>migra_info_2305161827.xml: </message>
D|MT|core.runners.base|||                </details>
D|MT|core.runners.base|||            </dump-status>
D|MT|core.runners.base|||            <dump-status dump-status="WRONG-FORMAT" backup-process-status="">
D|MT|core.runners.base|||                <details>
D|MT|core.runners.base|||                    <message>migra_info_2305161827.xml:
D|MT|core.runners.base|||Line 283 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 312 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 340 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 371 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 402 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 431 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 462 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 490 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 519 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 548 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||
D|MT|core.runners.base|||Line 582 error: Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.
D|MT|core.runners.base|||</message>
D|MT|core.runners.base|||                </details>
D|MT|core.runners.base|||            </dump-status>
D|MT|core.runners.base|||            <storages>
D|MT|core.runners.base|||                <storage>local</storage>
D|MT|core.runners.base|||            </storages>
D|MT|core.runners.base|||        </dump>
D|MT|core.runners.base|||    </data>
D|MT|core.runners.base|||</response>
D|MT|core.runners.base|||
D|MT|core.runners.base|||stderr:
D|MT|core.runners.base|||exit code: 0
W|MT|core.utils.restore_hosting_utils|||Failed to import Plesk configuration dump: backup file is not valid or corrupted.
W|MT|core.utils.restore_hosting_utils|||Migration will try to continue, but there could be issues when restoring hosting settings.
D|MT|core.utils.restore_hosting_utils|||Imported backup id reported by pmmcli is '2305161827'
[/CODE]
 
I don't see any obviously wrong content but the "deyployer-action" notice. That should not fail the whole backup though. There is no workaround for that at the moment. One recommendation I found here in documentation was to backup the content on the source server and restore it to the target instead of using Migrator. If this workaround is not feasible for you, please contact Plesk Support so that support staff can try to solve this issue for you on your server(s).
 
I still have the

Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.

issue in the latest Plesk Obsidian 18.0.57 Update #5 / Plesk Migrator 2.25.2-1922.

One recommendation I found here in documentation was to backup the content on the source server and restore it to the target instead of using Migrator.

Which table(s) would need to be migrated manually?

Or can I just remove the deployer-action attributes from the plesk.backup files and replay them into the target server? How?
 
The message sounds serious...
Code:
Failed to import Plesk configuration dump: backup file is not valid or corrupted.
Migration will try to continue, but there could be issues when restoring hosting settings.
...but at the upper level it's only a warning and the mail users seem to be there.

Can it be ignored?
 
I still have the

Element 'mailuser', attribute 'deployer-action': The attribute 'deployer-action' is not allowed.

issue in the latest Plesk Obsidian 18.0.57 Update #5 / Plesk Migrator 2.25.2-1922.



Which table(s) would need to be migrated manually?

Or can I just remove the deployer-action attributes from the plesk.backup files and replay them into the target server? How?

If the backup file is not big (less than 2GB), please perform the following:
1. Download the file via Plesk > Domains > domain.com > Backup & Restore. Click on the green arrow to download the backup file. Make it password-protected; otherwise, all the passwords will be reset.
3. On the new server, create the new subscription if it doesn't exist yet.
3. Upload the .tar archive to the new server via Plesk > Domains > domain.com > Backup & Restore > Upload. Select the file created in step 1, enter the password, and click OK.
4. Restore the subscription data from the backup.

If it is required to download the server-wide backup made via Tools & Settings > Backup Manager, please use the Tools & Settings > Backup Manager paths instead.
 
Last edited:
I don't see any obviously wrong content but the "deyployer-action" notice. That should not fail the whole backup though. There is no workaround for that at the moment. One recommendation I found here in documentation was to backup the content on the source server and restore it to the target instead of using Migrator. If this workaround is not feasible for you, please contact Plesk Support so that support staff can try to solve this issue for you on your server(s).
I have this problem too. Could you forward this to the devs or should i file a bugreport?
 
Plesk doesn't care about solving this, just check this: https://support.plesk.com/hc/en-us/...-Plesk-migrator-does-not-migrate-some-objects.

They only care about increasing prices every single year. And for what? Yes the price increase is needed to improve the product (= Plesk) and fix bugs. 10000% BS. This bug was according to the KB 6+ months old, but this thread was started back in May 2023... So this bug is almost 2 years old and Plesk doesn't care about fixing it...

...but when you are late with your payment. They ring you up the next day! Absurd.

Plesk is really, really getting bad for a 550+ Euro per year hosting "solution".
 

Attachments

  • plesk_migration_tool_bug_6_months_unresolved.jpg
    plesk_migration_tool_bug_6_months_unresolved.jpg
    239.6 KB · Views: 8
your frustration may understandable, but there is no need to burry up an one year old thread to write a negative statement about their prices and hijack the thread. let everyone handle the situation about prices and the increasement on their own. if you are frustrated then it is time for you to leave and let plesk behind you. migrate your server(s) to a new panel and enjoy your life without plesk whithout pouring negative vibes into this thread.
 
your frustration may understandable, but there is no need to burry up an one year old thread to write a negative statement about their prices and hijack the thread. let everyone handle the situation about prices and the increasement on their own. if you are frustrated then it is time for you to leave and let plesk behind you. migrate your server(s) to a new panel and enjoy your life without plesk whithout pouring negative vibes into this threa You are missing the point.
Ah, thank you, hschramm, for your enlightening wisdom. I didn't realize that addressing long-standing, unresolved issues in a professional product was akin to "pouring negative vibes." Clearly, the rest of us who've invested tens of thousands into Plesk licenses should just move on and let you, the self-appointed voice of reason, handle everything. Bravo.

But you're absolutely right—why waste time holding a multi-million euro company accountable when we can just pretend everything is perfect? After all, those yearly price increases must surely mean that Plesk cares deeply about fixing bugs... right? Oh wait, that would require them to actually resolve issues like the one I mentioned—issues that have been around for years. But hey, as long as you're happy with your licenses, Plesk must be doing a stellar job.

Maybe you should go ahead and buy a few more licenses. I'm sure Plesk's investors will be thrilled, and you'll get a gold star for your loyalty. Just don't come crying to the forums like a toddler when you run into the same issues and realize the "550+ Euro per year solution" doesn't quite live up to its price tag.

Thanks again for your valuable input. I'll be sure to take your advice—right after Plesk takes care of basic product functionality. Until then, enjoy your blissful ignorance.
 
@HHawk I completely understand that you are frustrated with Plesk, but that is not an excuse to be arrogant and condescending towards other forum users. Although you are free to express your negative opinion of Plesk, being rude with other users is something that won't be tolerated on this Forum.

Plesk like any other software product doesn't have unlimited human resources. Naturally, some issues get prioritized over other depending on the severity and impact user-wise. That particular bug occurs in very specific circumstance, therefore, it affects a very limited number of users and a workaround is already offered. If you are personally experiencing the issue on your server(s) and the workaround suggested is not convenient enough please do get in touch with our support team so they can attempt to provide a more suitable option. If you do not have option to get direct support, please provide me with the errors logged on your server in a private message and I will do the best of my ability to help out.
 
Last edited:
@HHawk I completely understand that you are frustrated with Plesk, but that is not an excuse to be arrogant and condescending towards other forum users. Although you are free to express your negative opinion of Plesk, being rude with other users is something that won't be tolerated on this Forum.

Plesk like any other software product doesn't have unlimited human resources. Naturally, some issues get prioritized over other depending on the severity and impact user-wise. That particular bug occurs in very specific circumstance, therefore, it affects a very limited number of users and a workaround is already offered. If you are personally experiencing the issue on your server(s) and the workaround suggested is not convenient enough please do get in touch with our support team so they can attempt to provide a more suitable option. If you do not have option to get direct support, please provide me with the errors logged on your server in a private message and I will do the best of my ability to help out.


Thank you, Sebahat, for stepping in and addressing my concerns. I appreciate the effort to maintain civility within the forum, and I understand your role in ensuring a constructive dialogue. That said, I feel it's important to address a few points in your response.

First, my "arrogance" and "condescension" were not directed at other users per se but rather at the systemic frustrations that come with paying a premium for a product that consistently leaves long-standing issues unresolved. If my tone appeared harsh, it's because it reflects the experience of many Plesk users who feel that their concerns are ignored—especially when bugs linger for years without meaningful resolution.

Second, while I acknowledge that Plesk cannot allocate infinite resources, the argument that this particular issue only affects a "limited number of users" does little to justify the delay. As you know, even niche problems can create significant operational challenges for businesses relying on your software. Moreover, presenting workarounds as a sufficient resolution, rather than fixing the underlying problem, feels dismissive of the trust we place in Plesk to provide a stable, professional solution.

Finally, suggesting that I reach out to support for a more "suitable option" is unhelpful. The issue is not unique to my environment—it’s a confirmed bug, acknowledged in your Knowledge Base. Redirecting users to support only masks the real problem: Plesk’s apparent unwillingness to prioritize fixing known flaws, even over a prolonged period.

I don’t doubt your willingness to help on a personal level, and I do appreciate that. However, I think we both know that addressing the frustration here goes beyond private messages or isolated fixes—it’s about trust. And trust erodes when users feel they’re paying more each year for a product that doesn’t prioritize solving core issues.
 
Sidenote: Of course, I already created a support ticket with Plesk (ID 95433747). Doh. The initial response, and I partially quote, was: "This has been reported as bug ID PMT-4938, which will be fixed in future updates." Reference: Plesk KB Article.

"In future updates"? That response was infuriating, to say the least. This bug is almost two years old. It should have been resolved a very, very long time ago—especially when Plesk justifies its price increases by stating, and I quote:

"We are adjusting our prices to ensure we can continue investing heavily in product development and grow our partner ecosystem. Furthermore, we plan to launch even more new solutions to support our journey to becoming the leader in server, web infrastructure, and WordPress automation solutions."
Source: Plesk Price Adjustment Announcement.

How seriously can these claims be taken when bugs this old, acknowledged in the Knowledge Base, remain unresolved?

Back to the support ticket—after I expressed my frustration regarding the support representative's response, the issue was suddenly escalated to the Plesk developers with the highest priority. So yes, apparently showing frustration does work. Though let me be clear: my "anger" is entirely justified and motivated by the lack of timely resolutions for critical issues.
 
Hi @HHawk, I'm the Director of Plesk Product Management.

Sidenote: Of course, I already created a support ticket with Plesk (ID 95433747). Doh. The initial response, and I partially quote, was: "This has been reported as bug ID PMT-4938, which will be fixed in future updates." Reference: Plesk KB Article.
I've prioritized PMT-4938 for developers, and we will check if it can be fixed.

The delay with the fix of this issue is related to:
1. In 2024, we spent 6+ months rewriting the Migrator functionality from EOLed Python 2 to Python 3 to improve the product's security. During this timeframe, we were blocked from any fixes and improvements. We are preparing a scope of improvements for Migrator for the current year and have already started investing more resources in this feature.
2. As Sebahat mentioned above, we have limited resources and are not fixing all the known issues. It's always a choice based on demand and the impacted audience.
3. When the issue first appeared, our devs couldn't reproduce it, so it was put on hold until more details or reports were available.

I hope this helps to clarify the issue.

First, my "arrogance" and "condescension" were not directed at other users per se but rather at the systemic frustrations that come with paying a premium for a product that consistently leaves long-standing issues unresolved. If my tone appeared harsh, it's because it reflects the experience of many Plesk users who feel that their concerns are ignored—especially when bugs linger for years without meaningful resolution.
I can fully understand your frustration. I'm open to a constructive dialogue about the long-standing technical issues with Plesk that may affect your business.

Please create a separate thread with a list of issues so we can check them individually.

This is not a promise to fix everything, but at least I can bring transparency to our decisions.

Though let me be clear: my "anger" is entirely justified and motivated by the lack of timely resolutions for critical issues.
Thanks again for your valuable input. I'll be sure to take your advice—right after Plesk takes care of basic product functionality. Until then, enjoy your blissful ignorance.
Once again, I fully understand your dissatisfaction with our product and am willing to discuss how it can be improved.

However, arrogance and a sarcastic tone towards users and our staff are not welcome on this forum. This is the first and only warning - you will be banned if it is repeated.

Best wishes, Anton.
 
Back
Top