The platform under the ERP: cloud only, and straight about what runs in a browser
AIMS360 runs on Microsoft Azure. There is no on premise version, no server for you to buy or patch, and no upgrade quoted as a project. Backups run continuously with a 35 day recovery window, data is encrypted three ways, access is set by role and every change is logged. And the part most vendors leave out: the full ERP is still a desktop application today, with the browser platform expanding every month.
Is AIMS360 cloud or on premise?
Cloud. There is no on premise version of AIMS360 and no option to install it on a server in your own building. The platform runs on Microsoft Azure, so the hardware, the redundancy, the patching and the physical security are Microsoft's responsibility rather than yours.
That distinction matters more in apparel than in most industries, because the load is seasonal. An on premise system has to be sized for market week and the pre season order surge, then sits underused the rest of the year. You pay for the peak twelve months a year. Cloud infrastructure absorbs the peak without you provisioning for it.
The part worth separating: cloud hosted does not automatically mean browser based. Your infrastructure problem is solved. Your browser access is partly solved and improving monthly. The next section is specific about which is which.
The infrastructure line items that disappear
Most of what an IT review asks about is work that no longer exists on your side rather than work AIMS360 does differently.
| What you would own on premise | What happens on AIMS360 |
|---|---|
| Buying and sizing servers | No servers to buy. Capacity is Microsoft Azure infrastructure |
| A server room, power and cooling | Azure data centers, with their own power, cooling and networking |
| Operating system and database patching | Handled as part of the platform, at night, outside working hours |
| A second site for disaster recovery | Replication to a geographically separate region, included for every customer |
| Hardware refresh every few years | Nothing to refresh. There is no hardware on your side |
| Version upgrade projects | Upgrades, maintenance, support, training and change management are covered by the subscription |
| Somebody on staff to keep it up | Nobody on your team owns infrastructure |
Desktop, browser and handheld, and which is which today
This is the question where vendors let the word cloud do work it has not earned. Here is the actual state.
Anywhere Cloud
The full AIMS360 ERP runs in Azure and you reach it from wherever you are: an office, a home desk, a showroom during market, a warehouse. Nothing is installed on a server you own and nothing is tied to one building.
Runway, browser and mobile
Runway is the browser based, mobile friendly platform. It runs from anywhere and on handheld scanners, which is what covers warehouse and scanner work without a workstation.
The core ERP is still a desktop application
Being straight about it: the full ERP is a desktop application today, not a web app. That is the part people assume cloud already solves, and right now it is only partly true.
The browser version grows monthly
Runway gets new features every month. The expectation is that most people will do almost all of their day to day work in the browser within about a year, with the complete version roughly two years out. If browser access for a specific role is a requirement, ask where that role sits on the roadmap rather than assuming either answer.
Four layers, and what each one actually closes
An apparel ERP holds more than orders. It holds landed cost, margin by account, wholesale price lists, factor and credit information, customer terms and the full retailer relationship. That is competitive intelligence, and it is the data a brand can least afford to lose.
| Layer | What it protects | How |
|---|---|---|
| Infrastructure | The network and application edge | Microsoft Azure hosting, with Azure Firewall at the network layer, Azure Web Application Firewall at the application layer, and Azure Monitor with active threat detection |
| Encryption at rest | The stored database and its backups, if the underlying files were ever obtained | Transparent Data Encryption in Azure SQL using AES-256. Database files, log files and backups are encrypted on disk |
| Encryption in transit | Data moving between your device and the AIMS360 environment | TLS on connections, so traffic cannot be read if intercepted on the network |
| Column level encryption | The most sensitive individual fields, even from someone who can already query the database | Sensitive information is encrypted inside the database, so reading the underlying tables does not reveal those values in plain text |
| Cardholder data | The single most attractive target in the system | Payments are tokenized by PCI DSS compliant processors. AIMS360 stores a token and a transaction reference, never card numbers |
| Development practice | Production data being copied onto a laptop to reproduce a bug | Development work uses cleansed data or an isolated sandbox rather than your live records |
The column level layer is the one most systems skip. Encryption at rest protects against a stolen disk. It does not protect a sensitive field from anyone who can already open a legitimate database session, which is what narrows the blast radius of a compromised credential.
Two numbers worth stating separately
Most uptime claims blur the contractual commitment and the operating record into one figure. They are different numbers and both belong on the page.
What the system is actually up
The AIMS360 operating figure has been 99.99 percent. Separately, the signed service level agreement attached to the master agreement commits AIMS360 to commercially reasonable efforts at 100 percent availability and defines service credits if availability falls below 99 percent in a billing month. Maintenance is excluded because it runs at night, outside working hours, which is the only definition of uptime a shipping department cares about.
Redundancy is the architecture, not an add on
Multiple copies sit at the primary data center and are replicated to a second in a geographically separate region. Every customer gets that arrangement at no additional charge rather than buying disaster recovery as an upgrade.
A 35 day undo button
Backup runs continuously as point in time protection rather than as a nightly job, so recovery targets a specific moment down to the minute rather than whatever a job happened to write at 2am. The window is 35 days and it is in the subscription. Nobody on your team schedules it, monitors it or maintains it.
The failure that actually happens
Hardware is rarely what takes a brand down. People are. Somebody picks the wrong date range and deletes a batch of orders, or a revised cost file imports over a season of landed costs. A nightly backup answers that by losing the day. Point in time recovery answers it by naming the minute things were still correct.
Who can see it, and who changed it
Two features that only work properly together, and both of them depend on one rule: individual logins, never a shared one.
Role based access control
Permissions attach to roles rather than to people, and each person gets a role. A warehouse team member, a sales rep and a controller each see what their job requires, and costing and margin can be restricted from staff who do not need them. Edit the role once and everyone in it updates.
- Three building blocks: users, roles, permissions
- Set up during implementation, then adjusted as the team changes
- A smaller menu is faster to work, so restricting access usually speeds people up
- Role based access control
The change log
Most arguments inside a brand are about a value that used to be something else: the ship date that moved, the quantity that shrank, the terms nobody remembers agreeing to. AIMS360 keeps a change log on the records where that happens, showing the field, the old value, the new value, the named user and the timestamp, on a tab inside the record itself.
- Eleven modules tracked, chosen for where the money and the disputes are
- Optionally extended to quantity movements on a style
- A record, not an undo button: restoring is backup and point in time recovery
- Audit trail
A shared login makes both of these worthless. Every log entry names the account that was signed in, so one shared account across a department produces a log where every line says the same useless thing, and a role that covers everybody's job is not a permission model. Individual logins with roles are what turn the log into evidence.
Your own fields, your own code, and somewhere safe to try both
One REST API across the whole ERP
Styles, customers, orders, pick tickets, inventory, WMS, work in process, invoices, RMAs and reports. JSON in, JSON out, read and write, with public documentation, a downloadable OpenAPI document and a written deprecation policy.
- 33 documented modules and roughly 790 endpoints as of September 2026
- GET, POST, PUT, PATCH and DELETE, so an integration can create and update, not only read
- Bearer token auth, either client credentials for server to server or the authorization code flow for an app acting on behalf of a user
- Regional base URLs, versioned paths and at least 90 days' notice before a major feature is removed
- Open API
The other door: read only database access
AIMS360 also allows read only ODBC and OLEDB connections to your own SQL database, with separate credentials issued by support. The two get confused, so the rule of thumb: if you are writing code other people will depend on, use the API, which has a versioned contract and a deprecation policy. If you are pulling raw tables into a BI tool for yourself, the database connection is faster to set up and the table structures can change with releases.
Custom fields
Every brand tracks something the software did not ship with: a sustainability claim, a buying group, a container number, the wash house that did the job. Add them as real fields across nine modules in three types, with no developer and nothing quoted.
- Styles, style color size, customers, customer orders, vendor purchase orders, cut tickets, garment dye, pick tickets and materials
- Dropdown, text and date, with up to ten dropdown categories on a style
- They reach saved views, the Excel export and the BI tools. They do not reach the standard printed reports
- Custom fields
A sandbox with your own data in it
Every customer gets a second, separate demo company at no additional charge. Ask support to restore a copy of your live data into it and your team can train, evaluate a feature before switching it on, or wire up a new integration against records they recognize.
- Two separate databases that share nothing
- A countdown on entry and a banner while you work, so nobody enters a real order in the wrong company
- Nothing flows back. There is no promote, no export to live and no merge
- Sandbox and test environment
What to know before you plan around it
These are the constraints we would rather you heard from us than found in month two.
| Constraint | Detail |
|---|---|
| The full ERP is a desktop application today | Runway is the browser and mobile platform and it expands monthly, but the complete web version is not here yet. If browser only access is a hard requirement for a specific role, ask where that role sits rather than assuming. |
| Ask about compliance documentation directly | Microsoft holds the certifications for the Azure data centers and hardware. That is not the same as a certification held by AIMS360, and no vendor should let you infer one from the other. Ask your AIMS360 contact for the current documentation rather than reading it off a hosting provider's page. |
| Thirty five days is a window, not an archive | An error introduced fourteen months ago is not recoverable by rollback. If you need a long term historical archive, export on a schedule and keep it yourself. |
| Rollback is a range, not a record | Returning to a moment means the work recorded after that moment is part of the conversation, which is why recovery is handled with the Support Center rather than triggered by a button. Calling early beats calling late. |
| Audit trail coverage is not universal | Eleven modules are tracked and vendors is not yet one of them. Retention also depends on your plan, the module and the record status, so there is no single number true for every customer. |
| Custom fields are not on the standard printed reports | They reach views, exports and BI. To group a printed report by one, the route is the report editor or the grid with the field as a column. |
| A required custom field has no escape hatch | Once a field is mandatory nothing saves without it, through any route including the API. Make a field required when the business genuinely cannot proceed without it, not when you would prefer people filled it in. |
| The sandbox is a one way street | There is no mechanism to promote work from the demo into live. It is also a snapshot rather than a mirror, so a fresh restore before a serious evaluation is worth the wait. |
| API access depends on your plan | Confirm with your implementation manager before scoping an integration. Permissions are also the ceiling: short or empty responses are usually a permissions problem rather than an API problem. |
| Exporting before you leave is your responsibility | Your data is yours and the API or Live Excel will pull it out at any time. After termination AIMS360 may erase customer data, so export before you go rather than after. |
What each part of the AIMS360 platform does
Hosting, security, backup, access control, the audit trail, the API, custom fields and the sandbox, one page each.
.png)
.png)
.png)
.png)
Common questions
What IT, finance and operations ask before a brand moves its order book into a cloud ERP.
Cloud. There is no on premise version of AIMS360 and no option to install it on a server in your own building. The platform runs on Microsoft Azure, so the hardware, redundancy, patching and physical security sit with Microsoft rather than with you. You do not buy servers, size them for market week, replace them in year five or staff somebody to keep them running.
Partly, and this is worth being precise about. Runway is the browser based, mobile friendly platform and it runs from anywhere including handheld scanners, which covers warehouse and scanner work without a workstation. The full ERP is still a desktop application today. Runway gains features monthly, with the expectation that most people will do almost all of their daily work in the browser within about a year and the complete version roughly two years out. Cloud hosted and browser based are two different things and any vendor should tell you which they mean.
On Microsoft Azure. The data centers, hardware and hypervisor are secured by Microsoft, and AIMS360 configures the controls on top: Azure Firewall at the network layer, Azure Web Application Firewall at the application layer, and Azure Monitor with active threat detection. Data is encrypted at rest with Transparent Data Encryption in Azure SQL using AES-256, in transit with TLS, and sensitive fields are encrypted at the column level so they stay protected even inside a legitimate database session.
No, and that is deliberate. The strongest way to protect cardholder data is never to hold it. Payments run through PCI DSS compliant processors that capture and tokenize the card, and AIMS360 stores only a token and the transaction reference. There is no cardholder data sitting in the ERP database to be exposed, which also reduces the scope of what has to be protected and audited on your side.
The operating figure has been 99.99 percent. That is separate from the contractual commitment: the signed service level agreement attached to the master agreement commits AIMS360 to commercially reasonable efforts at 100 percent availability and defines service credits if availability falls below 99 percent in a billing month. Maintenance does not count against uptime because it runs at night, outside working hours. Both numbers are stated because the operating record and the contractual floor are not the same thing.
Backup runs continuously as point in time protection rather than as a nightly job, so there is no window during the day when the last good copy is hours old. Recovery targets a specific moment down to the minute, and the window is 35 days. It is included in the subscription for every customer, with no storage line item and no retention upsell. Copies sit at the primary data center and are replicated to a second in a geographically separate region.
No. Replication to a geographically separate Azure region is part of the platform for every customer rather than a higher tier or a separate disaster recovery product. There is no second site for you to build, fund or test.
Yes. A change log records the field that moved, the value before, the value after, the named user and the timestamp, and it sits on a tab inside the record rather than in a separate reporting module, so the history of an order lives on the order. Eleven modules are tracked, chosen for where the money and the disputes are: customer orders, invoices, customers, pick tickets, styles, vendor purchase orders, cut tickets, garment dye, RMA and credit memos, shipment processing and more. It shows what a value used to be; it does not put it back.
It is the idea that permissions attach to roles rather than to individual people, and each person gets a role. A ten person brand has the same secrets as a hundred person brand: costs, margins, customer lists. Small teams often benefit most, because one person's mistake touches a bigger share of the business. It also tends to speed people up rather than slow them down, since a warehouse user looking at warehouse screens finds things faster than one staring at the full menu. Setup is part of implementation rather than an IT project.
Yes, one REST API across the whole ERP, covering 33 documented modules and roughly 790 endpoints as of September 2026. It carries GET, POST, PUT, PATCH and DELETE, so an integration can create an order, update a customer or receive a shipment rather than only pull a report. Authentication returns a bearer token, either through client credentials for server to server work or the authorization code flow for an app acting on behalf of a signed in user. There is public documentation, a downloadable OpenAPI document, regional base URLs and at least 90 days' notice before a major feature is removed.
Yes. AIMS360 allows read only ODBC and OLEDB connections to your own SQL database, with a server name, login and password issued by support. It is a separate capability from the API with separate credentials. The rule of thumb: use the API for code other people will depend on, because it has a versioned contract and a deprecation policy. Use the database connection for an analyst pulling raw tables into a BI tool, accepting that table structures can change with releases.
Yes, across nine modules: styles, style color size, customers, customer orders, vendor purchase orders, cut tickets, garment dye, pick tickets and materials. Three types are available, dropdown, text and date, with up to ten dropdown categories on a style. You name the field and it appears for every user, with no developer and nothing quoted or scheduled. The question worth asking any vendor is not whether custom fields exist but how far they reach: in AIMS360 they reach saved views, the Excel export and the BI tools, and they do not reach the standard printed reports.
Yes. Every customer gets a separate demo company alongside the live one at no additional charge, and support can restore a copy of your live data into it so your team works with styles, customers and orders they recognize. It is used for training new staff, evaluating a feature before switching it on, and testing an integration end to end. The rule to say out loud to every new user: nothing flows back. There is no promote, no export to live and no merge, so work entered there by mistake is retyped in live or lost.
No. Upgrades, maintenance, support, training and change management are covered by the subscription rather than quoted separately, and maintenance runs at night outside working hours so it does not take your team offline for a weekend. There is also no hardware refresh cycle on your side, because there is no hardware on your side.
Where the platform touches the rest of the system
Last reviewed 16 September 2026 by the AIMS360 team. Platform, hosting and API details reflect the AIMS360 configuration as of that date; API module and endpoint counts were taken from the public documentation in September 2026 and the documentation is the source of truth for what exists today. Product and company names belong to their owners.
Bring the infrastructure question
Bring your IT reviewer, your security questionnaire or the one thing your last vendor would not answer straight. We will walk the hosting, the encryption layers, the recovery window and the permission model against your own requirements, and tell you plainly where the edges are.
