You want to modernize your core business systems, but orders and shipments cannot stop. When sales and inventory systems have been in place for years, deciding where to begin can be difficult. News of cyberattacks makes that decision harder still.
In Japan, 123 ransomware incidents were reported in the first half of 2026, the highest half-year total since the second half of 2020. Tokyo Metropolitan Police Department's report on ransomware
At the same time, should people continue opening screens, checking information, and handing work to the next person at every stage from order receipt to shipment and invoicing? With limited staff and time, we at Kijitra believe that integrating AI into core operations is an unavoidable part of staying competitive.
We envision a core business system in which AI receives an order, gathers the information it needs, and moves the work forward under defined conditions, while people handle exceptions and important decisions. Kijitra recommends AWS as the foundation for this approach because it lets a company delegate infrastructure maintenance while designing processes and permissions around its own operations.
This article compares on-premises systems, SaaS, and AWS from the perspective of core business operations, then explains how Kijitra would incorporate AI and migrate from existing systems.
Modernization should change the work people do between systems
Core business systems support the operations at the heart of a business: purchasing and sales orders, inventory, sales, production, and accounting. Even with a new interface, the burden remains wherever people still connect those systems through manual work.
Consider order processing at a wholesaler. A member of staff reads an order email, matches product names to internal item codes, and checks stock. They look up customer-specific prices and payment terms, and contact suppliers if anything is out of stock. They then register the order, instruct the warehouse to ship it, and arrange invoicing as deliveries take place.
Even with separate sales, warehouse, and accounting systems, people may still have to re-enter data, reconcile records, and check information across departments. Orders have arrived, but they cannot move forward until someone checks them. This is the way of working Kijitra wants to change with AI.
AI should be able to read an order, call the necessary systems, and move on to the next step. That requires interfaces for reading and writing business data, a defined sequence of operations, and clear conditions for approval. We believe that modernizing core systems for the AI era means considering which units of work can be delegated, alongside moving the servers.
On-premises systems also need protection against intrusion and disruption
Keeping a system on company premises does not by itself make it secure. Japan's National Police Agency describes attacks in which intruders exploit unpatched vulnerabilities or leaked credentials through VPN devices and other remote-access routes to enter an internal network. National Police Agency's ransomware guidance
Even if a core system is not directly exposed to the internet, maintenance access routes and connected systems need scrutiny. If an attacker gets in, which data can they reach? If order and inventory records become unavailable, how soon can they be restored, and to what point? These operational questions matter alongside the physical location of the system.
On October 22, 2026, JPCERT/CC issued an alert about a critical vulnerability in PHP, a programming language used in web systems. Affected systems require patching and investigation for signs of compromise. JPCERT/CC's alert
When a problem like this arises, a company needs a process for identifying affected systems, testing updates, and applying them. In a system modified over many years, unclear configurations and uncertainty about what an update might break can make remediation itself difficult. Moving to AWS does not remove application vulnerabilities: the software in use still needs to be updated.
If a system remains untouched because it cannot be allowed to stop, fixes and improvements keep being postponed. Modernization also needs to provide an environment for testing changes while operations continue, together with procedures for recovering from failures.
Compare SaaS, on-premises systems, and AWS by flexibility and operational responsibility
SaaS provides ready-made business software as a service and can reduce the burden of implementation and maintenance. On-premises systems allow a company to manage its own equipment and connectivity. Building on AWS, Amazon's cloud platform, lets a company design a custom system while delegating part of the infrastructure management.
These are not equivalent categories: a SaaS product may itself run on AWS. Here, we compare three ways to support core operations: using an existing service, operating on company-owned infrastructure, or building within the company's own AWS environment.
| Option | Benefits for core operations | Questions for implementation and operation |
|---|---|---|
| SaaS | Makes standard business functions easier to adopt, with maintenance handled by the provider. Built-in AI features may also be available. | Does it fit your trading terms? Are there limits on integrations, data export, permissions, incident response, or adapting to contract changes? |
| On-premises | Can accommodate factory equipment, existing devices, and strict connectivity restrictions. | Who will keep equipment and software updated, monitor systems, and handle recovery? Can the company also maintain the infrastructure and integrations needed for AI? |
| Your own AWS environment | Lets you combine custom business processes with AI and design data access and execution permissions. Managed services can reduce maintenance work. | Can you sustain development and operations? How will you prepare for misconfiguration, excessive permissions, and AWS outages? Have you estimated development and maintenance costs as well as service charges? |
If a SaaS product fits your sales or accounting processes, using it is a sensible choice. More custom development also means more work to maintain. When choosing SaaS, check not only its features but also user authentication, activity records, data export, and deletion. UK government guidance on selecting and managing SaaS
If you want to apply AI to complex customer-specific terms or work that spans several systems, however, some parts will need your own design. You can also keep existing SaaS products and build the layer that moves work between them on AWS.
Why Kijitra recommends AWS: balancing control with maintenance work
Kijitra recommends AWS because it allows companies to build their own core business processes while delegating equipment and infrastructure maintenance. For example, Amazon RDS provides mechanisms that support database backups and software updates. With managed services, where the provider handles management tasks, a company can devote more attention to business rules and data. What Amazon RDS manages
This division of responsibilities has conditions. What AWS handles differs by service, and customers remain responsible for their applications and access permissions. With Amazon EC2 virtual servers, customers are also responsible for updating the operating system inside them. AWS shared responsibility model
What Kijitra values is the ability to reduce the scope of in-house maintenance while retaining the controls the business needs. That does not mean AWS is the safest or cheapest option for every company. The right configuration is one the company can sustain, taking account of the people running it, incident response, and future changes.
How Kijitra would design order-to-invoice operations on AWS
The following is a design example based on wholesale order processing. It illustrates Kijitra's proposed approach; it is not a case study of an implementation for a particular company. The aim is for AI to handle routine orders and hand exceptions to staff with reasons and possible courses of action.
AI receives an order and moves the work forward
When an order arrives from a customer, AI extracts the products, quantities, and requested delivery date. For an expression such as “the usual products next Tuesday,” it checks transaction history and the product master to suggest matches. If several products could fit, the order remains unconfirmed until the ambiguity is resolved.
Once products and quantities are clear, the system checks stock, prices, and trading terms. If stock is available, the order matches registered terms, and it is eligible for automatic processing, it reserves inventory and proceeds from order registration to shipping instructions. When shipment results arrive, the confirmed quantities are passed on for invoicing.
If there is a shortage, AI gathers options such as shipping from another warehouse, making a partial delivery, or purchasing more stock. Staff receive more than an “out of stock” alert: they see information such as whether another warehouse can meet the requested date or whether a split delivery would incur extra shipping costs. An authorized person decides on changes to delivery dates or prices.
This design aims to reduce the need for people to open several screens for every order, leaving more time for exceptions. The scope of automation expands as order types and data quality are assessed.
Separate the operations AI selects from the mechanisms that finalize transactions
In core business systems, correctly finalizing orders and amounts matters more than producing a plausible answer. AI is given interfaces for actions such as checking inventory or registering an order. These interfaces, through which systems interact in defined ways, are called APIs.
An inventory reservation API, for example, checks stock again when it executes and updates it so that the same stock is not allocated to two orders. Business rules independently validate prices, transaction limits, and approval requirements, rather than relying on the AI's response. AI is not given permission to rewrite records freely or change approval conditions. The design must prevent instructions embedded in an order email from bypassing permissions or approvals.
On AWS, we would consider the following components according to their roles.
| Role | Example configuration |
|---|---|
| Read orders and choose the next required operation | Use AI models through Amazon Bedrock. The application validates and executes operations proposed by the model. |
| Check inventory, validate trading terms, and register orders | Implement business APIs with services such as AWS Lambda, which delegates server management to AWS. Restrict permitted operations by user and process. |
| Manage pending approvals, failures, and resumption | Track workflow state with AWS Step Functions. Pause when a human decision is needed and resume after approval. |
| Store confirmed order, inventory, and invoice records | Consider Amazon RDS or similar services for newly built components. Check supported configurations and integration specifications for existing packaged software. |
Business APIs validate and execute the operations AI selects. When approval is pending or a failure occurs, processing stops and moves to the appropriate next response. Implementing and testing this division of responsibilities against real business requirements connects AI's decisions to actual transactions.
Transaction identifiers and execution results are tracked so that retrying after a connection failure does not create duplicate orders or invoices. Records also show which order triggered an operation, under which permissions, and what was executed. During an incident, new AI-driven processing can be stopped so that people can assess the situation and take over.
Limit connections and data use to what the work requires
Processes handling core business data should be allowed only the connections and operations they need. Amazon VPC provides a logically isolated network on AWS, and we would consider a configuration that keeps databases off the public internet. Bedrock also supports connections that do not traverse the public internet. This controls the network path; it does not place the AI model inside your own VPC. Private connectivity to Bedrock
The information sent to AI should also be limited to what is needed to process orders. Input and output retention conditions must be checked for the chosen model, region, and settings. Depending on those conditions, Bedrock may retain data or allow human review, so the decision needs to be based on the particular combination you will use. Bedrock data retention conditions
Protection must cover processing histories and backups as well as order data. Choose storage arrangements that avoid losing backups in the same incident, and test whether operations can resume by reconciling restored data with pending orders. The design needs to verify both data restoration and the ability to resume transactions without duplication.
Migrate one business process at a time
There is no need to replace sales, warehouse, and accounting systems all at once. Keep existing systems running, separate out one business process, and gradually connect it to the new components built on AWS. AWS's migration guidance also describes this approach of replacing existing functions incrementally. AWS's incremental migration pattern
For order processing, start by reading orders and preparing proposed entries, then compare them with the results produced by current staff. At this stage, do not register production orders automatically. Test both routine orders and exceptions to check whether products are identified correctly and unusual trading terms are captured.
Next, limit the scope to selected customers or products and register only approved orders through the business APIs. After verifying that cancellation and reprocessing work correctly, move routine orders that meet the conditions to automatic execution. Once order processing is proven, extend the approach to shipping, invoicing, and payment reconciliation.
During migration, decide which system holds the authoritative order and inventory records. If the old and new systems independently update stock, the numbers will diverge. Design how to handle synchronization delays, outstanding orders at cutover, and the conditions for returning to the previous way of operating.
Working screens alone do not prove a successful migration. Check order processing times and how often staff have to intervene. Check entry errors, duplicate processing, recovery within the required time, and operating costs before deciding whether to move on to the next business process. If the current system has no integration interface, begin by establishing one and checking the product's support conditions.
Make modernization the point where AI starts moving work forward
Kijitra envisions a future in which AI connects everyday work from order receipt through shipment, invoicing, and payment confirmation, while people focus on exceptions and improvements. In the morning, staff review completed orders alongside shortages and special trading terms awaiting decisions. We want to make that way of working possible through the design of core business systems.
The first step is to list the operations that cannot be allowed to stop and those held up by manual checks or data entry. Separate the parts of the current system worth keeping from those that need to be rebuilt so AI can take them on, then decide the order of migration.
If you are considering core system modernization and AI together, talk to Kijitra. We can discuss the systems you use today, the work people connect manually, and the operations that cannot stop, then consider together what to retain, where to begin moving to AWS, and which processes to entrust to AI.