The cloud, infrastructure and identity your applications run on.
Hosting and deployments, migrations between providers, databases, sign-in and access, OAuth connections, and DNS and TLS. Planned in writing before anything changes, and verified on the running system afterward.
Fixed price, agreed in writing after a written plan. What moves it: the number of systems involved, and how narrow any downtime window has to be.
What this covers
The layer applications depend on. Each item is planned on its own or bundled, with one price.
Application hosting and deployments
Where the application runs and how changes reach it: hosting, environments, background jobs, and a release path with tests and review, so shipping a change is routine.
Cloud and hosting migrations
Applications and databases moved between providers, with a cutover plan, DNS and TLS, replication and load balancing, and the downtime agreed in writing before it happens.
Databases
The database the application depends on: structure, access, backups, and moves between hosts, with the data checked on arrival.
Identity and access
Sign-in, roles, and who can reach which data, in the application and in the admin consoles around it. Access mapped to roles, stale accounts closed, and a record of what changed.
OAuth and API connections
The tokens, service accounts and API keys that connect your systems. Scopes kept narrow, token refresh handled, failures made visible instead of silent, and secrets kept out of code. See the connected-app review guide.
DNS, TLS and mail authentication
Domains, certificates and records everything else depends on, including SPF, DKIM and DMARC so receiving servers can verify mail from your domain.
Business workspaces too. The same work applies to Google Workspace and Microsoft 365: admin roles and groups, offboarding gaps, connected apps, and mailbox or tenant migrations, with mail flow verified before the old system is switched off.
How infrastructure work runs
Planned in writing, so nothing changes in your systems that you did not approve.
- A look first: the current setup, what depends on it, and where the risk sits. Nothing is changed at this stage.
- The plan: the changes, their order, how to roll back where it matters, and any downtime window, agreed in writing.
- The change: only what was approved, logged as it happens, and checked on the running system.
- Handoff: documentation of the new setup, the checks that show it works, and access back in your hands.
- Timeline
- Set in the plan. Migrations are scheduled around your downtime window, usually outside business hours.
- Access needed
- Read access to look. Write access only for the approved changes, then removed.
- You get
- The change made and verified, documentation of the new setup, and a record of what changed.
Infrastructure work delivered
Deliveries on the infrastructure and identity side.
Application and database moved from Azure to OVH for Classlete
- Problem
- A PHP Laravel application and its SQL database had to leave Azure for OVH without taking the product down.
- Done
- Infrastructure and database moved with a short downtime window, SSL and DNS cut over, Windows VMs replicated and load balanced on the new host.
- Result
- The application on its new hosting, moved with minimal downtime.
QuickBooks to Mailchimp integration repaired for Gabriel Service and Repair
- Problem
- A customer sync between QuickBooks and Mailchimp that stopped whenever OAuth tokens expired or the server restarted
- Done
- Token validation and refresh rebuilt, tokens persisted in a database so the sync survives restarts, the whole pipeline validated end to end
- Result
- A sync that runs without anyone re-authorizing it by hand.
Shared-drive ownership and access rebuilt for Ingersoll Support Services
- Problem
- Shared drives, groups and personal drives had grown over time, and access needed a clear structure.
- Done
- Shared Drive architecture by department, role-based access through Google Groups and permission tiers, personal-drive migrations, and a provisioning workflow written down.
- Result
- Access that matches the org chart and survives staff changes.
Guides you can use this week
The checklists VXSec works from, free. If you get through one and want the rest done, send it back with what you found.
- Offboarding gap checklist: what to check when an employee or contractor leaves.
- Google Workspace access checklist: the access review for a Workspace tenant.
- Microsoft 365 offboarding checklist: the same, for a Microsoft tenant.
- Connected-app and OAuth review: how to find every app with access to your tenant.
- Sample report: what the written report looks like, finding by finding.
Questions about infrastructure work
Is VXSec a managed service provider?
No. This is project work with a fixed price and a handoff, with ongoing engineering available if you want VXSec to keep running and improving the systems afterward. Agencies and MSPs that want to resell the delivery can read the partners page.
Will anything break during the work?
The first look changes nothing. Changes are applied only as approved and logged as they happen, with a rollback planned for the risky ones. Migrations have a downtime window agreed in writing.
Can you take over infrastructure someone else set up?
Yes. The first step is a look at the current setup and what depends on it. The plan for changing it follows in writing.
What needs building or fixing?
Tell VXSec what the system does, what you want to change, and what is getting in the way. Include links if you have them. Within two business days you get a written reply with the next step.
Or email [email protected] directly.
- You send: what should happen, what happens now, and the systems involved. No diagnosis needed.
- You get back: a written reply with the next step. For a defined job, a plan and a fixed price.
- Then: the work, verified and handed over in writing.