A separate demo company alongside your live database, loaded with a copy of your own data on request. Train new staff, evaluate a feature before you switch it on, and test a new integration end to end. Nothing entered there reaches your live orders, stock or accounting.
Every AIMS360 customer gets a second, separate company database to break things in. Ask us to restore a copy of your live data into it and your team can learn, test a feature you have not switched on, or wire up a new integration against records they recognize. Nothing in there can touch a real order, a real invoice or a real stock figure.
Yes. Alongside your live company, AIMS360 gives you a separate demo company: a complete second database that looks and behaves like the real system, at no additional charge. Ask Support to restore a copy of your live data into it and you get your own styles, customers, orders and users to work with. Everything you do there stays there.
That is the whole idea. A mid sized brand cannot afford to learn a new module by trying it on Tuesday's shipments, and nobody wants to find out how a new ecommerce connection behaves by pointing it at the live order book. The demo company is where that risk goes.
A new coordinator can enter orders, allocate, pick, ship and invoice against data they will recognize on their first real day. Nobody gets shipped by accident and nobody gets billed by accident, so people try things instead of asking permission. It is the fastest way to get someone useful.
Some settings in an ERP are one way doors. Others simply change how a department works every day. Intelligent allocation, production tracking and bin locations are all easier to decide on after a week of using them somewhere harmless.
Where a partner offers a test account, connect their sandbox to your AIMS360 demo company. Styles go out, orders come back, and you can watch the whole loop before a single real product listing or customer order is involved.
A new size scale convention, a restructured customer list, a different way of coding warehouse locations. Doing it once in the demo turns a risky migration into a checklist, and usually surfaces the two things nobody thought of.
An empty demo is not much use. A demo holding last week's version of your business is.
Send a request to AIMS360 Support asking for a copy of your live data to be restored into your demo company. Say what you are planning to test, because it sometimes changes what we set up alongside it.
Building the copy is not instant. You are notified on the same support ticket when the demo is ready to use, so there is nothing to watch for in the meantime.
From inside AIMS360, click your initials in the top right and choose to close this company and open another. From the login screen, pick it there instead. If you run several company databases, the demo is always the last one listed.
There is a short countdown when the demo opens, and the words Demo Company sit at the top of the screen for as long as you are in it. Both exist for the same reason: people forget.
When you are done, log back into your live company to do real work. Ask for a fresh restore before the next big test rather than reusing a copy that has drifted months out of date.
AIMS360 will let you keep your live company open and open the demo alongside it, but that second session consumes another of your licensed users. On a busy day that is the license somebody else needed. Closing the live company first and reopening it afterwards avoids the problem entirely.
| In the demo company | What that means for you |
|---|---|
| Separate data | The two databases share nothing. Orders, styles, stock, invoices and accounting in the demo are a copy at best and unrelated at worst. Live is never affected by anything done there. |
| Separate users | User setup is its own. A login that works in live does not automatically exist in the demo, which is why an invalid operator message usually means no restore has been done yet. A restore brings your users and their roles across. |
| A countdown on entryBy design | Opening the demo pauses for a few seconds before it lets you in. It is a deliberate speed bump so nobody walks into the wrong company on autopilot. |
| A banner while you workBy design | Demo Company is displayed at the top of the screen throughout. It is the only visual difference once you are inside, so it is worth pointing out to new users on day one. |
| Some features limitedBy design | A small number of things are deliberately restricted in the demo. If a test depends on one of them, ask us rather than concluding the feature does not work. |
| Nothing flows backHard rule | There is no promote, no export to live, no merge. Work entered in the demo by mistake is retyped in live or it is lost. |
| Replaced on refresh | A new restore overwrites what is there. Anything from a test worth keeping should be written down outside AIMS360 first. |
Connect the partner's sandbox or test account to your AIMS360 demo company, not to live. Several of the platforms brands connect to offer a test account before they hand over a production one. Pairing their test account with your demo company gives you a full round trip with nothing real at either end.
That matters more than it sounds, because integration problems are rarely about whether the connection works. They are about what happens to your data once it does. Styles arrive with the wrong images. Orders import against a customer that does not exist yet. A sync that looks fine in one direction does something surprising in the other. All of it is cheap to discover in a demo and expensive to discover in live.
Enough to prove the loop works in both directions. Pushing a full catalog into a test site creates cleanup on the partner side and teaches you nothing extra.
Send product out, place an order on the partner side, watch it come back in, then ship and invoice it. A one way test is half a test.
A canceled line, a partial ship, a customer with unusual terms. Ordinary orders always work. It is the exceptions that decide whether you go live.
Once the loop is proven, the same setup is repeated against your live company and the partner's production account, with the mapping decisions already made.
The same approach applies to development work against the AIMS360 open API. Point your build at the demo company while you are writing it, so a mistaken call hits a copy rather than the order book. See platform technology for how the pieces fit together.
Updates are implemented and validated in an isolated environment that mirrors production before they are released. Changes are exercised away from live customer databases first, so a release reaching your company has already been run somewhere that looks like your company.
This is separate from the demo company you use. Yours exists for your training and testing. Ours exists so that a change we make does not arrive on your Tuesday as a surprise. Both matter, and confusing the two is a common source of crossed wires in a conversation about testing.
For the infrastructure underneath both, see Anywhere Cloud, data security and data backup and recovery.
There is no mechanism to promote work from the demo into live. Every hour spent entering real data into the wrong company is an hour spent twice. Tell people this before you give them the login, not after.
A restored demo reflects your business at the moment the copy was taken and then stops. It does not track live. Long running tests slowly become tests against a world that no longer exists, which is why a fresh restore before a serious evaluation is worth the wait.
The demo is designed to be overwritten. Continuous protection and point in time recovery apply to your live database, not to a practice copy. Nothing that matters should exist only in the demo.
None of which is an argument against using it. It is an argument for using it deliberately: ask for a fresh copy, agree what you are testing, keep the test small, and write down what you learned somewhere that survives the next refresh.
Yes. Every AIMS360 customer gets a separate demo company alongside their live company at no additional charge. It is a full AIMS360 database that behaves like the real thing, so staff can be trained in it, a feature can be tried before it is switched on in live, and a new integration can be tested end to end. Nothing entered there touches your live orders, stock or accounting.
They are two completely separate databases. Different data, different users, different logins. Work done in one never appears in the other. The demo company also announces itself: there is a short countdown when you log in and the words Demo Company sit at the top of the screen the whole time you are in it.
Yes, and it is the first thing to do. Ask AIMS360 Support to restore a copy of your live database into your demo company. Once that is done the demo holds your styles, customers, orders and user logins as of the moment the copy was taken, so testing happens against data your team recognizes rather than sample records.
Usually a couple of business days from the point the request goes in. You are told through the same support ticket when it is ready. Because it is a point in time copy it starts going stale immediately, so ask for a fresh one before a big test rather than reusing a copy from last quarter.
No. The demo company is provided to AIMS360 customers at no additional charge. What can cost you is leaving two sessions open at once, because keeping your live company open while you open the demo consumes a second user license out of your allowance.
Two ways. If you are already in AIMS360, click your initials in the top right and choose to close this company and open another, then pick the demo from the list. If you are not logged in, choose it at the login screen instead. Brands with several company databases always find the demo listed last.
Because your user has not been created in that database. The demo and the live company keep entirely separate user setups, so a login that works in live does not automatically exist in the demo. Requesting a restore of your live data brings your users across with it.
No, and this is the single most important thing to know before you hand it to a team. Data cannot be transferred between the two systems. Anything typed into the demo by mistake has to be typed again in live. It is a practice environment, not a staging area that promotes work forward.
Yes, that is the most common use. A new coordinator can enter orders, cut a pick ticket, run an allocation and print an invoice against familiar data without any chance of a real customer being shipped or billed. Mistakes cost nothing, which is what makes people learn faster.
Yes. Features that are irreversible in a live database, or that change how a team works day to day, are exactly what a demo company is for. Try intelligent allocation, production tracking, bin locations or a new report layout there first, then decide whether to enable it in live.
Yes. Where the partner offers a sandbox or test account of their own, connect their test account to your AIMS360 demo company rather than to live. That gives you a complete test loop with no risk on either side, which is how most brands set up a new B2B or ecommerce connection.
Not much. Ten or so styles and three to five customers is enough to prove the connection works in both directions. Sending your whole catalog to a test site creates cleanup work on the partner side and tells you nothing that a handful of styles would not.
Some functionality is deliberately restricted in the demo. That is a design decision rather than a fault, and it means a small number of things behave differently there. If a test depends on something specific, check with us first rather than concluding from the demo that a feature does not work.
Yes. Updates are implemented and validated in an isolated environment that mirrors production before anything is released, so changes are exercised away from live customer data first. That is separate from your demo company, which exists for your own testing and training.
Point development work at your demo company rather than at live. The AIMS360 open API is the same interface either way, and testing against a restored copy of your own data means a bad call cannot corrupt real orders. Talk to us before you start so the right database is connected.
It is replaced. A refresh restores a new copy of your live data over the demo company, so anything created in the previous copy goes away. If a test produced something you want to keep, such as a report layout or a documented set of steps, record it outside AIMS360 before asking for the refresh.
Whoever is training or testing. Because the demo keeps its own user setup, access there is separate from access in live, and a restored copy brings your live roles and permissions with it. See role based access control for how permissions work in either database.
Treat it as disposable. Your live database is what carries continuous point in time protection and a rolling recovery window. The demo exists to be overwritten, which is precisely why it is safe to experiment in, and why nothing of record should ever live only there.
The setting nobody wants to be the one to switch on. The integration that has been on the roadmap for a year. The process change that needs four people to agree. Show us one of those and we will set your demo company up so you can try it properly before anyone commits.
