Adding a smart contract does not require moving an entire business application onto a blockchain. Existing databases, staff tools, and payment systems can remain in place.
A hybrid design gives the contract a defined job, connects it to the information that job requires, and leaves other responsibilities with the software already handling them. The practical question is which parts of a process need to interact.
An AWS reference architecture published in April 2026 describes this division: business data stays in a cloud database while an oracle network supplies outside information to blockchain code.
Image Source: Editorial illustration by author
This network delivers a report to a smart contract. The contract receives information for its blockchain role, while the company retains a separate system for recordkeeping.
Decide what the contract needs
A smart contract is a program deployed on a blockchain. On Ethereum, it executes programmed rules using information available within that environment. It cannot independently open the company’s accounting database or read a bank’s records. Information from those systems must reach it through an external connection.
Start with the action the contract would perform and work backward to the information required. Which fact allows the action to proceed? Which application records that fact? Those questions define a much smaller task than copying everything the business stores.
Keep a separate list of tasks that do not depend on that action. Record retention, staff access, and ordinary reporting can continue in existing applications. Define any changes those applications need, including how they expose the required information and how they receive results from the contract.
An oracle supplies the connection between external information and blockchain code. When delivering real-world data for smart contracts, it obtains information from outside the chain and presents it in a form the receiving contract can use. The original business system remains responsible for its records; the contract applies its programmed rules to the information delivered. A report about a payment and the payment itself therefore belong to different parts of the process.
The information crossing that boundary needs a precise meaning. A request to begin an action is different from confirmation that the action has finished. Decide which one the contract requires before selecting the fields to send. Transferring a message does not transfer responsibility for everything described in it.
Follow the report through the systems
The AWS design concerns reserve information, meaning records about assets backing a digital asset. Amazon DynamoDB stores the source data. Amazon API Gateway routes requests to AWS Lambda, which processes the stored information. These services remain outside Ethereum.
A scheduled Chainlink workflow retrieves the reserve data, checks the resulting value against a configured minimum, and produces a signed report for a contract on Ethereum. The database retains the raw information for recordkeeping and auditing. The blockchain receives the reported value.
Image Source: Infographic by author
AWS presents this as a reference design for developers. It does not document a customer’s production deployment. The contract receives an input without taking over the database’s recordkeeping role, leaving the business responsible for maintaining the underlying records.
Assign each responsibility
Before implementation, name the system responsible for each part of the proposed process. A responsibility map can expose unanswered questions even before developers choose the connection technology.
| Responsibility | System to identify | Question to settle |
| Maintain business records | Existing application and database | Who can create or correct the source record? |
| Deliver external information | Oracle and connected services | Which information must reach the contract? |
| Apply programmed rules | Smart contract | What action does an accepted input permit? |
| Record completion | Relevant business application | What evidence allows the business record to change? |
Give each responsibility an owner as well as a system name. Otherwise, an architectural diagram can show a complete connection while leaving nobody accountable for correcting source records or investigating an incomplete operation. Document who can approve changes to the agreed business rules.
Include a correction procedure in that ownership discussion. The team needs to decide how amended source records affect information already delivered to the contract, rather than assuming both systems will automatically agree.
Completion deserves its own definition. A contract accepting information does not, by itself, establish that a separate banking or administrative process has finished. The application displaying a completed status should use evidence appropriate to the action it describes.
A fund pilot using existing payments
Financial infrastructure offers a documented example. In its January 2026 account of digital asset interoperability trials, Swift references work with UBS Asset Management and Chainlink connecting tokenized assets with existing payment systems.
That pilot was announced on November 5, 2024. It addressed purchases and redemptions of tokenized fund holdings, where blockchain tokens represent fund interests. Existing Swift infrastructure supported the payment process, while Chainlink coordinated interactions needed before the fund could create or remove tokens. Cash settlement remained outside the blockchain.
The pilot demonstrated a particular connection between established infrastructure and blockchain activity. It did not establish that every organization can reuse its software unchanged, or that the arrangement is appropriate for every business process, but it is still a useful starting point.
For a software project, the decision starts with the proposed contract’s specific job. Identify the source records, the information that must cross into the blockchain, and the evidence existing applications need afterward. Then assess the changes required at those boundaries. Ask for a plan that identifies those changes before treating the project as a full software migration.
