This guide is for administrators updating an existing installation, including standalone Paper servers and Velocity/BungeeCord networks. It focuses on preserving voting data and having a tested rollback before replacing a JAR.
Version baseline (November 2026): The latest published stable release is VotingPlugin 7.1.1, published July 23, 2026, and compiled for Java 21. Changes on the
master/7.2-SNAPSHOT development line may not exist in that stable release. Check the release list and Spigot resource for the exact artifact being installed.
Record:
Config.yml → DataStorage: SQLITE or MYSQL, including relevant driver and database type.Do not assume a feature documented for a development commit is in the published stable JAR. If the wiki labels something development-only, verify the feature against the actual artifact you are upgrading to.
Take a coordinated, consistent recovery point while all data writers are stopped. Announce a maintenance window, stop external vote intake, and cleanly shut down every participating server and proxy before copying the plugin files, Users.db, or the shared SQL database. VoteShop purchases, scheduled resets, background saves, and queued rewards may continue writing even after external voting stops. An alternative is a genuinely coordinated application-consistent snapshot of both SQL storage and all plugin files, with writes quiesced across every node. Do not copy Users.db while its server is live.
Back up the whole plugins/VotingPlugin/ folder rather than just one YAML file, including files normally generated by the plugin. Take the SQL dump and file snapshots within the same stopped/quiesced maintenance window so they represent a matching restore point.
| Environment | Minimum backup |
|---|---|
| Standalone / SQLite | Users.db and entire VotingPlugin configuration/data directory, plus previous VotingPlugin and Votifier listener JARs |
| Standalone / MySQL | Consistent SQL database backup plus configuration/data directory and previous JARs |
| Proxy network | One consistent SQL backup and all proxy/backend VotingPlugin configuration directories, selected listener configuration, and previous plugin JARs |
| Optional Control integration | Its separately managed backup/snapshot plan; do not assume a VotingPlugin folder copy includes the Control service's state |
Never edit ServerData.yml directly; backing it up is different from modifying it. Protect copied SQL credentials, Votifier private keys, proxy secrets, and backups themselves.
A file-only backup is not sufficient for an SQL-backed installation, and rollback without restoring related data may leave counts/points/streaks inconsistent.
/vote, website links, rewards, vote points, streaks, VoteParty, and monthly/daily resets./av vote <player> <site> test and also a real/listener-generated Votifier test; the internal command does not verify the public listening port.Do not run a staging listener against a production voting website and database—that could create duplicate votes or reward effects.
/reload or a hot-swap.Config.yml and VoteSites.yml with release defaults without overwriting local customizations.See Getting Started: Standalone for where the files live.
The normal released topology installs VotingPlugin on the proxy and all participating backends, with a shared SQL database and a compatible Votifier listener on the proxy.
BungeeMethod (usually PLUGINMESSAGING).Server name and the proxy and backends use compatible SQL settings and matching communication channels./votingpluginproxy status, then test internal forwarding and a real/listener-generated vote into the proxy.See Proxy Setups and Votifier Troubleshooting for the transport options and tests.
Do not blindly downgrade a running server or keep writing to a database with incompatible versions.
Rollback can lose activity between the backup and failure. A recoverable backup and a maintenance window matter more than a quick JAR swap.
Do not combine an ordinary JAR upgrade with a storage or UUID migration unless you have tested the exact combination.
The storage migration guide documents /av converttodata <storage> and /av convertfromdata <storage>. These commands copy user data and do not change DataStorage automatically. Back up source and destination, pause vote intake, verify the copy, switch storage, and restart only after confirmation.
For existing proxy networks, keep the supported shared-SQL layout; a local SQLite backend is not a drop-in replacement for the shared database.
Changing OnlineMode or BedrockPlayerPrefix can change which identity receives votes, points, and rewards. Coordinate proxy/backends and plan a separate migration with backups and verification; do not flip these settings just to fix a single unmatched vote.
See Online / Offline Mode and Bedrock Player Support.