Migrating a Shop Plugin to InfiniteShops
By PM2, the developer behind these plugins ·
If you already run a shop plugin, the only question that matters is how much of your existing shop survives the move. InfiniteShops ships a converter, and this page is the honest reading of it: the sources it is stated to read, the fields it is stated to carry across, the places the record and the docs say nothing at all, and the order to do the cutover in so your economy is never live and half-configured at the same time.
What /ishop convert is, and what is actually claimed for it
InfiniteShops ships a migration command, and its own record states the scope in one sentence: run /ishop convert to import shops from ShopGUIPlus or EconomyShopGUI, and categories, items, prices, layouts and pagination are imported automatically; EssentialsX users can also generate a sell shop from their worth.yml price list. The plugin costs €16.85 (price at time of writing) and runs on Spigot and Paper 1.13 through 26.2.
The on-site FAQ and troubleshooting doc, imported from the plugin's own wiki, adds the exact syntax and one source the product page does not mention: /ishop convert essentials, /ishop convert shopguiplus and /ishop convert bossshoppro. Note the two spellings you will meet — the product record writes ShopGUIPlus, the wiki heading writes ShopGUI+, and the subcommand itself is lower-case shopguiplus.
Two gaps are worth naming before you plan around them, because an honest gap is cheaper to discover here than at 2am on cutover night. First, the docs list a BossShopPro subcommand but neither the record nor the docs describe what that conversion carries across. Second, the record names EconomyShopGUI as a supported source while the three documented examples do not spell out a subcommand for it, so check /ishop help in game rather than guessing at a spelling. One disclosure as well: InfiniteShops is the only shop plugin we sell, so this is a migration guide and not a comparison — nothing here is a judgement about the plugin you are leaving.
The four sources, and how far each one is stated to go
A converter is worth exactly as much as the part of your setup it understands, so it helps to see the four paths next to each other with the unknowns left visible instead of smoothed over. The middle column is what our record or the on-site docs say the import produces; the last column is what neither of them states.
| Source format | Command | What is stated to come across | What is not stated |
|---|---|---|---|
| ShopGUI+ (ShopGUIPlus) | /ishop convert shopguiplus | Categories, items, prices, layouts and pagination, automatically | Anything beyond GUI shop content — no sign, frame, player, NPC or Daily Shop content is claimed |
| EconomyShopGUI | /ishop convert — named in the record; the docs list no separate subcommand | Categories, items, prices, layouts and pagination, automatically | The exact subcommand spelling; confirm it with /ishop help before the cutover |
| BossShopPro | /ishop convert bossshoppro | The docs give the command; the scope of the import is not described anywhere | What it carries across at all — plan for a test run rather than a result |
| EssentialsX worth.yml | /ishop convert essentials | The worth.yml price list becomes a sell shop instead of being re-entered by hand | Buy prices — the record describes a sell shop, not a two-sided one |
Reading that table before you commit to a date
The differences between those four rows are the whole decision. The ShopGUI+ and EconomyShopGUI path is the only one described field by field, and those fields — categories, items, prices, layouts, pagination — are most of what a GUI shop is, so that migration is genuinely a command rather than a project. If that is where you are coming from, the work after the command is walking every category and fixing what looks wrong — how long that takes depends on how many items you had.
The EssentialsX path is not a shop migration at all and should not be scheduled like one. A worth.yml is a price list, the record describes the result as a sell shop, and nothing states that buy prices come out of it. Treat it as a head start on the sell side of a shop you are still going to build, which is exactly how the record frames it: import worth.yml and turn it into a sell shop instead of re-entering every price.
The BossShopPro path is the one to be careful with. A documented command with an undocumented scope is not a plan, and inventing a scope for it here would be the least useful thing this page could do. Run it once on a test server against a copy of your configuration, look at what appears in game, and size the remaining work from what you actually see. The docs also keep a manual path for exactly this case: export the old shop data, create new shop files in plugins/InfiniteShops/shops/, map items and prices by hand, and test thoroughly before going live.
What to have in place, and the order to do it in
The record names two hard dependencies — ProtocolLib and Vault — and adds that everything else is optional and auto-detected. The docs list a third requirement in practice: an economy plugin for Vault to talk to, with EssentialsX and CMI given as the examples. The first-install doc lists the rest of the prerequisites: Java 17 or higher, and a Vault-compatible economy plugin, with EssentialsX and CMI given as the examples. If you are arriving from EssentialsX worth.yml, you already have that half in place. The catalogue-wide dependency guide puts those requirements beside the other plugins here if you are installing more than one thing this week.
Two operational details matter more during a migration than during a fresh install. The install doc says to restart the server rather than reload it after dropping the jar in, and the integrations doc repeats the same instruction when a plugin is not being detected — restart, not reload. And the conversion command sits behind its own permission node: infiniteshops.convert, listed in the permissions reference as op by default. Every permission node is customizable in permissions.yml, so if your staff run migrations from a rank rather than as operators, set that up before you need it.
Where the converter writes its output is not stated in the record or in the docs. What is stated is where shop content lives once it exists: YAML files in plugins/InfiniteShops/shops/, one per category, with the shop system doc describing the file format down to slots, item types and economy types. Back up the old plugin's folder outside the server directory before you touch anything — the docs' own first tip is to always back up before making changes, and their second is to test on a development server first.
Do all of this on a test server first. Nothing in the sequence below is difficult, but every coin your players earn or spend passes through this plugin, and a mispriced converted category is a duplication bug with a friendly GUI in front of it.
- 1. Back up the old shop configuration — Copy the old plugin's folder somewhere outside the server directory; the docs' own first tip for success is "always backup before making changes".
- 2. Install the requirements — ProtocolLib, Vault and a Vault-compatible economy plugin, on Java 17 or higher — the prerequisites the first-install doc lists alongside Spigot or Paper.
- 3. Add the jar and restart — Drop InfiniteShops.jar in plugins/ and restart rather than reload; the console should report that it hooked into your Vault economy on start-up.
- 4. Grant infiniteshops.convert — The node defaults to op, so either run the conversion as an operator or grant infiniteshops.convert to the rank that will do the work in whichever permission plugin you use.
- 5. Run the subcommand for your source — /ishop convert shopguiplus, /ishop convert bossshoppro or /ishop convert essentials, as documented — and /ishop help if you are coming from EconomyShopGUI, whose subcommand spelling the docs do not give.
- 6. Walk every converted category in the editor — Open /ishop editor and check each item: the editor sets buy and sell prices, economy type per item, slots and categories point-and-click, and changes apply the moment you save — no reload, no restart.
- 7. Check every custom item — ItemsAdder, Nexo and Oraxen items work as shop products, display items and currency items with no extra setup, but whether an old file's references to them survive conversion is not stated — confirm each one renders and costs what it should.
What no import brings with it
The claims stop at shop content, and that is the right place to set your expectations. Everything below is a real part of InfiniteShops that no converted file is stated to produce, which means it is work you are doing after the import rather than work the command saves you. None of it is hard; all of it is easy to forget on the day.
- The currency on each item — InfiniteShops supports six payment sources — Vault, EXP, items, custom currencies, PlayerPoints and TokenEnchant — plus OR mode, where the player picks, and AND mode, which charges several at once; how an imported entry maps onto those ecoType values is not stated, so check the converted items rather than assuming Vault.
- The other six shop types — A GUI shop is one of seven types in the jar — GUI, Daily, Black Market, NPC, Sign, Frame and Player — and nothing says an import creates sign shops, frame shops, player chest shops or NPC vendors, the last of which are powered by Citizens and need it installed.
- Your permission grants — The nodes change names: infiniteshops.use, infiniteshops.shop.use, .buy, .sell and .sellall, plus infiniteshops.shop.<name> per category. Nothing states that the converter touches permissions at all, so plan to rewrite the rank grants by hand before players meet the new shop.
- Messages, titles and lore — Every player-facing message, GUI title and lore template is customizable with HEX colour ({#RRGGBB}) and PlaceholderAPI, and dedicated language files can translate the plugin — but the wording your players are used to is yours to re-enter.
- The feature toggles you have not thought about yet — The shipped config.yml carries eighteen feature switches and most default to on — black-market, daily-shop, sign, frame-shop, player-frame-shop, npc, taxes, shopper-rank, multipliers, limited-stock and transaction-logging among them, with dynamic-pricing, limited-sell and realistic-season off. Disabled systems register no listeners or scheduled tasks, so turn off what you are not ready to configure.
- Where your data lives — Player data can be flatfile, per-player files or MySQL, with SQLite used automatically for internal storage, and cross-server sync for stock, sell limits, dynamic prices and Daily Shop limits is off by default — decide this before launch, not after balances exist.
The cutover checklist
One conflict deserves planning rather than discovery. InfiniteShops registers /shop with the aliases /s and /shp, and if the plugin you are leaving also owns /shop, both are claiming the same command; the record does not state how such a conflict resolves, so remove the old plugin at cutover rather than leaving the two installed side by side on a live server. Keep the original folder until every line below is ticked.
- Every category opens — Each converted category opens from /shop and from its category button in the main menu, with pagination intact where the old shop had pages.
- Every price is right in both directions — Buy and sell prices match what you intended — and on an EssentialsX worth.yml import, remember that buy prices are not part of what the record claims.
- The command belongs to one plugin — /shop, /s and /shp resolve to InfiniteShops, with the old plugin removed rather than disabled-but-present.
- Ranks can still shop — infiniteshops.use plus infiniteshops.shop.use, .buy, .sell and .sellall are granted to the groups that had access before, along with any infiniteshops.shop.<name> node a category needs.
- Custom items render — ItemsAdder, Nexo and Oraxen products show the right model, name and price in the converted categories.
- Unconfigured features are off — Anything you have not set up — the Daily Shop, the Black Market, sign or frame shops, taxes — is toggled off in config.yml until it is ready.
- It ran on a test server first — The whole sequence has been done once against a copy of your configuration, which is the docs' own advice: "test thoroughly before going live".
Once the shop is yours again
A migration is a good moment to decide what you actually want the shop to be, because you are already re-reading every item. The in-game editor is the part that changes the day-to-day: items added from your hand, prices and economy types set per item, categories created live, inventory contents bulk-imported into a category in one action, and every change applied on save without a reload, which is what you want while you are still re-pricing converted categories.
From there, add layers only when each earns its place. Our InfiniteShops setup guide covers choosing among the seven shop types and a first-hour order that will not wreck a young economy, the full documentation is the plugin's own wiki, imported page for page, and the economy and shops category puts this plugin beside its Minecraft range and current version. If your migration is really a menu migration rather than a shop one, the DeluxeMenus to GUIPlus guide is the same kind of page for that converter.