Frequently asked questions

Axio Intelligence is a US engineering firm in San Antonio, Texas. We build go-to-market platforms for new product lines, data and AI platforms, and cloud infrastructure as code on AWS, Google Cloud and Azure; we build connected hardware end to end — firmware, cellular and satellite connectivity, device-to-cloud and edge AI; and we cut cloud costs, modernize legacy systems — including moving COBOL and RPG workloads off IBM mainframes and IBM i, and Oracle and SQL Server databases to PostgreSQL or MySQL — run DevOps/SRE and provide fractional CTO leadership.

Yes — it is one of the most common reasons established companies hire us. We build the product site, customer and dealer portals, commerce and billing, CRM and ERP integrations, and the cloud infrastructure for a new line, so it can launch without pulling the core engineering team off the roadmap.

AWS, Google Cloud (GCP) and Microsoft Azure. We build and support infrastructure as code with Terraform, OpenTofu, Pulumi, AWS CDK or Bicep, including landing zones, Kubernetes (EKS, GKE, AKS), CI/CD and ongoing IaC support.

Yes. For US manufacturers, distributors, wholesalers and mid-size retailers still running on IBM Z (z/OS and COBOL) or IBM i (AS/400 and RPG), we move COBOL and RPG workloads to AWS, Azure or Google Cloud in a modern language, starting with the batch and extract jobs that cost the most — inventory, replenishment, pricing feeds, reports. It starts with a diagnostic of the bill and the job list, and there is no upfront fee: we are paid a percentage of the net savings in licensing and compute spend.

Mostly established companies launching something new — a product line, a division, an AI or data capability, or a connected product — plus IoT connectivity providers who need an implementation partner, energy and DER device makers, defense and dual-use hardware teams, and industrial operators. We also built the AI data platform behind MLtwist.

Yes. We build the embedded firmware, the connectivity path, the device-to-cloud pipeline, command-and-control APIs, secure OTA updates and the fleet console, and we can design and manufacture the hardware too. One team is accountable from the board to the dashboard.

Most work starts with a short scoping sprint, followed by a fixed-scope, fixed-fee build with a written plan and dates. After launch, systems can move to a monthly support retainer. Fractional CTO work is a monthly retainer for a set number of days. Mainframe and IBM i migration is the exception: no upfront fee, priced as a percentage of the net savings we deliver. Database migrations can be either a fixed fee or a share of the license savings, depending on the job.

Yes. We build on the provider you already use, which is why connectivity providers refer their customers to us as an implementation partner.

Axio Intelligence is headquartered in San Antonio, Texas, and works with clients across the United States. Our engineering team is US-based.

Send an introduction. We run a joint scoping call within two business days, quote a fixed-scope project to the customer, and keep your partner manager updated through delivery. The customer contracts with us for engineering and with you for connectivity.

No. We build on the connectivity the customer already chose. If there is a real technical constraint, we raise it with you first.

Yes. Many providers use us as a white-label or co-branded engineering bench for application work that falls outside their core platform.

You need a reliable command path to every unit (usually cellular, not customer Wi-Fi), a supported interface — IEEE 2030.5, OpenADR or an aggregator API — acknowledgements and telemetry that prove the device responded, and a fleet console for your program partners. Axio builds all four.

Most existing utility programs still specify OpenADR 2.0b; OpenADR 3.0 is simpler to build against and gaining adoption. We usually recommend a VEN architecture that can speak both, so one integration covers current and upcoming programs.

Yes — as a gateway alongside the inverter or battery management system, or integrated into your controller — with a cloud command path your utility and VPP partners can dispatch against.

Yes. We build TAK plugins and CoT bridges that publish your device’s tracks, status and alerts into the operator’s TAK environment, alongside REST/gRPC connectors for other C2 platforms.

No. Axio Intelligence does not hold a facility clearance. Our engagements are unclassified — fleet software, commercial connectivity, test telemetry, integrations and data pipelines — and we are transparent about that in scoping.

Yes. We work as a software and hardware subcontractor to small businesses on SBIR/STTR and prototype awards, and as a teaming partner for integration work primes don’t want to staff.

Usually, yes. We add a gateway that reads existing controllers and sensors over Modbus or digital I/O and backhauls over cellular or satellite, so the installed equipment stays in place.

Yes. They are typical first candidates: they read IBM data and write a file, feed or report, so they can be rebuilt in the cloud and run side by side with the old job until the outputs match.

Yes. We migrate Oracle, SQL Server and Db2 to PostgreSQL or MySQL, converting schemas and stored procedures and keeping data in sync until cutover.

Bank deposit and money-movement cores, card authorization, insurance claims adjudication and government benefit systems. Our focus is manufacturers, distributors, wholesalers and mid-size retailers.

Yes. Established companies bring us in to build everything a new line needs to go to market — product site, portals, commerce and billing, integrations with the CRM and ERP you already run, and the cloud infrastructure — as a fixed-scope, phased build.

Either we hand off to the team you hire, with documentation, runbooks and help interviewing, or we keep running the platform on a monthly support retainer. You own the code either way.

Minimal. We need access, a few decisions from product owners and integration points into your systems. The build itself runs on our team.

Yes. We built the platform MLtwist runs on: project and workforce management, labeling projects, automated QC, and custom pipelines triggered on Kubernetes as containerized workloads. It is the foundation MLtwist delivered its $590K U.S. TSA multimodal labeling contract on.

No. MLtwist holds the TSA contract. Axio engineered the MLtwist platform that the work is delivered on.

Video, audio, images, text and 3D data, including security-imaging formats such as DICOS — preprocessed, labeled, quality-checked and packaged in the format the model team needs.

No. We replace components incrementally behind stable interfaces, with parity tests, so product work continues while the old system is retired piece by piece.

Yes, one job at a time. We move COBOL and RPG workloads off z/OS and IBM i to AWS, Azure or Google Cloud in a modern language, starting with the batch and extract jobs that cost the most, and dual-run them until the outputs match. See mainframe & IBM i migration.

Yes. We convert schemas and stored procedures, keep data in sync with change data capture, and cut over with a rollback path. See database migration.

Yes. We convert the schema and the PL/SQL packages, procedures and triggers to PostgreSQL, move the data with a bulk load and change data capture, and cut over once the application has run against Postgres with production-sized data.

Yes. T-SQL procedures, functions and triggers are converted and tested routine by routine, application queries are updated, and data stays in sync until cutover.

Usually only a short cutover window. Change data capture keeps the new database current while the application is tested against it, and the old database stays available as a rollback until you are confident.

PostgreSQL is usually the closer fit for Oracle and SQL Server workloads with heavy procedural code, rich types and complex queries. MySQL makes sense when your team already runs it or the workload is simpler. The assessment recommends one based on your code.

Either a fixed fee or a percentage of the license savings, depending on the job. When the goal is getting off Oracle or SQL Server licensing, a share of the savings usually fits; when the migration is part of a wider build, a fixed fee usually does. We recommend one after the assessment.

Yes. Db2 for z/OS and Db2 for i data moves to PostgreSQL as part of our mainframe and IBM i work, alongside the jobs that read it.

Owns the technical decisions a full-time CTO would — architecture, connectivity and cloud choices, security, hiring and vendor selection — for a set number of days per month, and can bring an engineering team to execute the plan.

An agency delivers a project. A fractional CTO is accountable for your technical direction across projects and vendors, including the ones we don’t build.

Yes — that is the most common way we start. We audit what exists (hardware, firmware, cloud, connectivity contract), keep what works, and ship the missing layer, usually firmware command handling, the cloud pipeline and a fleet console. You keep the code and the IP.

Yes. We build on the connectivity you already have — cellular, satellite or private LTE — and hand connectivity decisions back to you and your provider.

Usually AWS, and also GCP, Azure or your own infrastructure. We default to boring, well-supported managed services so your team can run the system after hand-off.

Signed images, staged rollouts by cohort, resumable downloads over constrained links, health checks after update, and automatic rollback. We design OTA before the first fleet ships, not after.

LTE-M suits devices that move, need lower latency or send more data, and it supports voice-grade handover. NB-IoT suits stationary, deep-indoor, very low-data devices. Many products ship modules that support both and choose per region; we test against real coverage before committing.

Yes. We design a failover path — typically 3GPP NTN or Iridium — with message prioritisation, so critical commands and alarms still get through when cellular is unavailable, without paying satellite rates for routine telemetry.

No. We work with the provider you choose and build on the network you already use, which is why connectivity providers refer their customers to us.

Yes. We size the model to the compute and power available — typically NVIDIA Jetson-class hardware — and send detections and events upstream instead of raw video.

A few weeks of representative telemetry and a list of the failures you care about. We start with simple statistical baselines that are explainable to operators, then add learned models where they earn their keep.

Yes. That is the point: one accountable team from the board to the console, so provisioning, OTA and field diagnostics are designed into the hardware from the start.

Yes. Most engagements start from an existing prototype or production design; we review it for manufacturability, connectivity and field reliability before building.

AWS, Google Cloud (GCP) and Microsoft Azure, including multi-cloud setups. We write the infrastructure as code — usually Terraform or OpenTofu, or Pulumi, AWS CDK or Bicep where a team already uses them.

Yes. We start by reconciling state with what is actually deployed, then refactor into modules, add a plan/apply pipeline and document it — without a big-bang rewrite.

Yes. A monthly IaC support retainer covers change reviews, provider and Kubernetes upgrades, drift cleanup, new environments and on-call escalation.

Yes. It uses read-only, audit-scoped credentials you can revoke at any time. Nothing is changed until you approve a plan.

It depends on the workload. Published benchmarks from the cloud providers and the FinOps Foundation commonly show 20–50% recoverable for teams that haven’t optimised before; the diagnostic gives you your actual number.

There is no upfront fee. We are paid a percentage of the net savings: the drop in your annual IBM and third-party licensing and mainframe compute spend once workloads move, after the cost of running them in the cloud, measured against a baseline we agree with you before work starts.

Yes. Mainframe software is licensed many ways — rolling 4-hour peak, full capacity, consumption-based or enterprise agreements — and the details vary by vendor and contract. Whatever the model, the bill follows the work on the mainframe. Moving that work to the cloud is what lets you license and run less of it.

It is a common way IBM and other vendors price z/OS software: the bill is based on the highest four-hour average of CPU use in the month, as reported by IBM’s Sub-Capacity Reporting Tool (SCRT). One busy window can set the bill for the whole month. It is one pricing model among several.

No. IBM i (formerly AS/400 and iSeries) is the operating system on IBM Power servers, licensed differently from IBM Z mainframes running z/OS. What the two share is decades of RPG or COBOL code that few people can still maintain, so we run them as separate diagnostics with separate goals.

No. We start with the batch and extract jobs that cost the most or carry the most risk, and move in waves. You can go all the way to a full migration, or stop when the remaining savings aren’t worth it.

Not up front. Each job only needs the files or tables it reads. We replicate those inputs to the cloud — as a scheduled extract or a change data capture feed — and widen the scope as more workloads move.

A written report and a live walkthrough: current-state architecture, ranked findings with risk and effort, and a roadmap. It is useful on its own — you are not obligated to hire us for the fixes.

Yes. Most builds move to a monthly support retainer covering monitoring, on-call, patching, OTA releases and a monthly reliability review. It is optional — we also document and hand off to your team.