Frequently Asked Questions
The questions our buyers ask, answered in one place
Every page-specific question across the site, aggregated and categorized. Each answer also lives on the page where the conversation usually starts. Use the category links below or jump directly to a specific topic.
Jump to a category
Category
About eWay Corp
How eWay operates and how an engagement is structured.
About eWay Corp
How eWay differs from a hosting provider, an agency, or a managed-WordPress vendor — and what an engagement actually looks like.
Visit the home page- What is Managed WebOps?
- Managed WebOps (short for 'Website Operations') and Cloud Infrastructure is a model where a single partner takes continuous operational responsibility for your entire digital platform. This includes cloud infrastructure, CMS platforms, application integrations, performance monitoring, security patching, and ongoing optimization. Unlike traditional hosting or development, Managed WebOps does not end at launch. It is an ongoing operating model with defined SLAs and human accountability for outcomes.More on the About eWay Corp page
- How is eWay different from a hosting provider?
- A hosting provider gives you servers. eWay gives you an operated platform. We manage the infrastructure, the CMS layer, the application integrations, and the performance of your digital environment as a continuous, accountable service. If something degrades, we find it before you do. If traffic spikes during enrollment or a campaign, your platform is already architected to handle it.More on the About eWay Corp page
- How is eWay different from a web development agency?
- Development agencies design and build and then move on to the next project. eWay does not hand off at launch. We remain the accountable operational partner for the life of the engagement. Your platform improves over time rather than slowly degrading between redesigns.More on the About eWay Corp page
- Which CMS platforms do you support?
- We specialize in Cascade, Drupal, WordPress and we manage the AWS or Azure cloud infrastructure underneath all three. If your institution uses multiple platforms across departments, we can manage them within a single operational engagement.More on the About eWay Corp page
- Do you work with AWS or Azure specifically, or both?
- Both. We are certified partners on AWS and Microsoft Azure. We architect your environment based on your institutional requirements, existing procurement commitments, and compliance obligations not based on which cloud we prefer.More on the About eWay Corp page
- What does an engagement with eWay actually look like?
- Engagements are structured as monthly managed services contracts under an annual agreement. You get a defined scope, clear SLAs, a dedicated team familiar with your environment, and regular performance reporting. Most engagements begin with a platform assessment, followed by an onboarding and migration phase, and then continuous operations.More on the About eWay Corp page
Category
Platforms
Cascade, Drupal, WordPress, AWS, and Azure under managed operations.
Cascade Website Hosting
Managed hosting for Cascade-published websites. eWay operates the production environment that receives Cascade's published output, not the Cascade CMS application itself (Hannon Hill operates that).
Cascade Website Hosting- What is managed hosting for Cascade CMS?
- Cascade CMS is hosted and managed by Hannon Hill as a SaaS product. But when you publish content, Cascade sends that output to a separate production web server that your institution controls. Managed hosting for Cascade means managing that production environment — the web server, CDN, security configuration, performance optimization, and everything else between Hannon Hill and your website visitors. eWay manages this infrastructure specifically for how Cascade deploys, which is different from how we would host a WordPress or Drupal site.More on the Cascade Website Hosting page
- What is Hannon Hill responsible for, and what does eWay handle?
- Hannon Hill operates the Cascade CMS application as SaaS. That includes the authoring environment, the publishing engine, content modeling tools, and the SaaS infrastructure on which the CMS itself runs. eWay Corp operates everything downstream of Cascade: the production web server that receives Cascade's published output, the CDN that delivers it to visitors, security configuration, performance optimization, monitoring, and the operational discipline that keeps the site running reliably 24 hours a day. The boundary is clean. Hannon Hill ends at the publish destination; eWay begins there.More on the Cascade Website Hosting page
- How is hosting Cascade different from hosting WordPress or Drupal?
- WordPress and Drupal are open-source applications that run on the production web server. Cascade is a SaaS application that publishes static output to the production web server. The hosting work is structurally different. For WordPress and Drupal, we manage the application itself: PHP runtime, database, plugin and module updates, CMS-specific security advisories. For Cascade, the application is Hannon Hill's responsibility, and we focus exclusively on the production environment that receives the published output. The infrastructure architecture, performance work, and operational discipline diverge accordingly. A team that hosts WordPress and Drupal well does not automatically host Cascade well.More on the Cascade Website Hosting page
- Our Cascade website is running slow. Can you fix it?
- Yes — and slow Cascade websites almost always have the same root causes: an under-configured production server, a poorly optimized CDN setup, or publish jobs that are creating server load that impacts front-end delivery. We begin with an infrastructure assessment to identify exactly what is causing the slowness, then address it through a combination of server configuration, CDN tuning, and caching strategy improvements. Most clients see measurable improvement within the first month of engagement.More on the Cascade Website Hosting page
- How do you handle large Publish All jobs and publish-driven traffic spikes?
- A Publish All from Cascade pushes thousands of files to the production server in rapid succession. On generic hosting, this looks like a sudden burst of file system activity that can exhaust inodes, fill SFTP queues, or trigger anti-abuse rate limits. We architect the production environment specifically for this pattern: dedicated network paths between Cascade and the production server, pre-warmed file system capacity, automated CDN cache invalidation that runs as the publish completes, and monitoring that alerts on partial publish completion. Most institutions see large publish jobs complete reliably during enrollment cycles without manual intervention or emergency support calls.More on the Cascade Website Hosting page
- Can you integrate our Cascade environment with our campus identity system?
- Yes. We configure and manage Single Sign-On (SSO) using SAML 2.0, LDAP, and Active Directory integrations so your staff authenticate into Cascade through your existing campus credentials. We also support API and webhook connections between your Cascade production environment and other campus systems where the integration lives at the infrastructure layer.More on the Cascade Website Hosting page
- We are currently hosted elsewhere. How difficult is migration?
- Migrating a Cascade CMS hosting environment is straightforward when planned correctly. We handle the full migration — provisioning the new environment, configuring CDN and caching, migrating content and server configurations, and validating publish behavior before cutover. We plan for zero unplanned downtime, and we include a free migration for qualifying engagements. Most migrations are completed within two to four weeks depending on environment complexity.More on the Cascade Website Hosting page
- Do you host on AWS or Azure? We have an existing agreement with one of them.
- We host on both AWS and Azure — and we design your environment around your institution's existing agreements, compliance requirements, and preferences. If your institution has an existing AWS or Azure enterprise agreement, we can provision within that framework. If you have no preference, we will recommend the architecture that best fits your Cascade deployment's specific requirements.More on the Cascade Website Hosting page
Managed Drupal Hosting for Government
Drupal as a fully managed WebOps platform for federal, state, local, and municipal government agencies on AWS GovCloud or Azure Government.
Managed Drupal hosting for government- Why Drupal instead of WordPress for government?
- Both are viable for government, and we operate both. Drupal is typically the better choice for governments with complex content governance requirements — granular role-based access control, structured content types with complex field relationships, multi-department multi-site architectures, multilingual citizen services, and strict content workflow and audit requirements. For county and state government platforms with 50+ departments and multilingual services, Drupal is almost always the right call.More on the Managed Drupal Hosting for Government page
- We are currently on Acquia. Can you migrate us off?
- Yes — this is a common engagement for us. Migrating from Acquia Cloud to eWay-managed AWS infrastructure eliminates Acquia licensing costs while maintaining full Drupal capability. The migration involves provisioning your environment pipeline on AWS, migrating the Drupal codebase and database, configuring search infrastructure, validating all integrations, and cutting over with no unplanned downtime. We handle the full technical migration and provide a cost comparison analysis before you commit to anything.More on the Managed Drupal Hosting for Government page
- How do you handle ADA Title II compliance and WCAG requirements?
- Title II requires WCAG 2.1 Level AA compliance for all public-facing web content, with active compliance deadlines now in effect for larger entities. We treat accessibility as a continuous operational discipline — not a launch audit. Development follows accessibility-first practices: semantic HTML, proper heading structure, ARIA implementation, keyboard navigation, and accessible color contrast. QA includes automated scanning and manual testing with screen readers. Post-launch, we monitor for accessibility regressions as content is added and features are updated.More on the Managed Drupal Hosting for Government page
- We have 50+ departments that all need their own section of the website. How does that work in practice?
- We architect a Drupal multi-site environment where each department has its own publishing space — its own URL path or subdomain, its own editorial team with role-scoped access, and its own content — while inheriting the shared design system, navigation architecture, accessibility configuration, and security posture from the central platform. New department sites are provisioned from a template in hours, not weeks. Central IT controls platform-wide changes. Department editors control their own content within defined boundaries.More on the Managed Drupal Hosting for Government page
- What procurement vehicles can we use to engage eWay?
- eWay is SBA 8(a) certified, a Minority Business Enterprise, a Disadvantaged Business Enterprise, and SBA Small Business certified — providing procurement pathways for agencies that can direct-award to 8(a) firms or set aside for these categories. We also work through standard competitive procurement processes, AWS Marketplace, and Carahsoft contract vehicles, and can support your team with the technical documentation required for government RFPs and RFIs.More on the Managed Drupal Hosting for Government page
Managed WordPress Hosting and WebOps
Enterprise WordPress operations for institutions running WordPress as a mission-critical platform — full-stack ownership, not commodity managed WordPress hosting.
Managed WordPress hosting and WebOps- How is this different from WP Engine or Kinsta?
- WP Engine and Kinsta are platform hosts — they manage the server and give you tools to manage WordPress. They do not patch your plugins, build or maintain your custom code, replace your search with OpenSearch, optimize your database queries, or architect your multisite network. eWay manages the full application stack, not just the infrastructure underneath it. If you need custom plugin development, enterprise search, complex integrations, or large-scale multisite operations, you need an operations partner, not a platform host.More on the Managed WordPress Hosting and WebOps page
- Do you manage plugin updates even for plugins with custom modifications?
- Yes — this is one of the most important things we manage. Plugins with custom modifications are the highest-risk update scenario in WordPress because standard update processes overwrite the modifications. We maintain a full inventory of which plugins have customizations, test updates in staging against those customizations, and apply updates only after validating that modifications are preserved and functionality is intact.More on the Managed WordPress Hosting and WebOps page
- Our WordPress search is unusably slow with 50,000+ posts. What does an OpenSearch implementation involve?
- A typical OpenSearch implementation involves provisioning a managed OpenSearch cluster on AWS or Azure, designing the index schema to match your content model (post types, taxonomies, custom fields), building the indexing pipeline that syncs WordPress publish events to the index in real time, and integrating the search API with your WordPress front-end. Most clients see search performance improve from multi-second response times to under 100ms after implementation.More on the Managed WordPress Hosting and WebOps page
- We manage WordPress for dozens of departments with different publishing permissions. How do you handle that?
- We implement a custom RBAC framework that maps your organizational structure to WordPress permissions: department-level content ownership, custom roles (author, editor, publisher, approver, administrator) with granular capability sets, and site-level or network-level permission boundaries in multisite environments. For organizations running Active Directory, Azure AD, LDAP, or SAML 2.0, we connect WordPress role assignment directly to your identity system — so access updates automatically without manual user management.More on the Managed WordPress Hosting and WebOps page
- We were hacked through a WordPress plugin. How do you prevent this?
- Plugin vulnerabilities are the most common WordPress compromise vector. Our approach combines prevention and detection: we track CVEs for every plugin in your environment and apply security patches on an accelerated timeline — typically within 24–48 hours of a security release for critical vulnerabilities. We run a WAF with WordPress-specific ruleset that blocks known exploit patterns even for vulnerabilities that haven't been patched yet. File integrity monitoring detects unauthorized changes to plugin code immediately.More on the Managed WordPress Hosting and WebOps page
- What AWS or Azure services do you use to host large WordPress sites?
- A typical large WordPress environment on AWS uses EC2 with auto-scaling groups behind an Application Load Balancer, RDS (MySQL or MariaDB) with read replicas for high-traffic sites, ElastiCache for Redis object caching, S3 for media storage with CloudFront CDN delivery, and OpenSearch Service for the search layer. On Azure the equivalent is App Service or AKS, Azure Database for MySQL, Azure Cache for Redis, Azure Blob Storage with Azure Front Door, and Azure OpenSearch. We design the specific architecture based on your traffic patterns, content volume, and budget.More on the Managed WordPress Hosting and WebOps page
Managed AWS Operations
AWS Solution Provider Partner for public-sector institutions. Full-stack accountability under a single managed engagement with defined SLAs.
Managed AWS operations- How is eWay different from Rackspace for AWS managed services?
- Rackspace is a strong infrastructure managed services provider with no CMS or WebOps capability. If your platform includes Drupal, WordPress, or Cascade CMS — which most public sector digital platforms do — Rackspace manages the infrastructure layer and leaves the application layer to you or a second vendor. eWay operates the full vertical: AWS infrastructure, CMS application layer, security controls, CI/CD pipelines, and ongoing operations under one engagement. One team. One SLA. No coordination overhead between an infrastructure partner and a CMS partner.More on the Managed AWS Operations page
- How do we procure eWay services? We're a government agency with procurement requirements.
- We support multiple procurement paths for public sector organizations. Direct engagement is available with standard government contract documentation. We are an AWS Marketplace seller — which means your organization can procure eWay managed services through an existing AWS Marketplace agreement, simplifying acquisition and often reducing procurement cycle time significantly. We are also available through Carahsoft using their established government contract vehicles. Our SBA 8(a), MBE, DBE, and SBA Small Business certifications support set-aside and direct-award procurement.More on the Managed AWS Operations page
- What does the shared responsibility model mean for our organization, practically?
- AWS's shared responsibility model means AWS secures the physical data centers and hypervisor infrastructure. Everything above that — operating system patching, network configuration, IAM policies, application security, WAF configuration, data encryption, audit logging, incident response — is your responsibility. Most organizations don't have the internal capacity to do this well across a complex multi-service AWS environment. That gap is exactly what eWay manages. We take ownership of every layer above the AWS hypervisor — so your team isn't carrying an operational burden they weren't staffed to handle.More on the Managed AWS Operations page
- How long does a migration from on-premises or legacy hosting typically take?
- Timeline depends significantly on environment complexity. A straightforward CMS platform migration — a single Drupal or WordPress site with a standard database and no complex integrations — typically completes in 6–10 weeks through our five-phase framework. Complex environments with multiple applications, legacy databases, custom integrations, or significant data volumes typically run 12–20 weeks. Discovery and architecture review in Phase 1 produces a detailed timeline with milestones before any migration work begins — so you have a commitment, not an estimate.More on the Managed AWS Operations page
- Do you support FERPA, HIPAA, NIST, or StateRAMP compliance alignment?
- We design and operate environments with alignment to the compliance frameworks most common in our public sector verticals: FERPA for higher education, HIPAA for healthcare, and NIST 800-53 and StateRAMP-aligned controls for government agencies. This means architecture decisions, IAM policies, encryption configurations, audit logging, and incident response procedures are designed to support your compliance posture — not bolted on afterward. We provide the documented evidence and control implementations that your auditors need.More on the Managed AWS Operations page
Managed Azure Operations
Microsoft Cloud Solution Provider for government and Microsoft-stack institutions. Azure Government, App Service, AKS, identity integration, and CSP licensing under one engagement.
Managed Azure operations- We already have SQL Server, ASP.NET applications, and Active Directory. Do we have to re-platform to move to Azure?
- No — and that's one of the core reasons government agencies choose Azure over other cloud providers. SQL Server runs natively on Azure Virtual Machines with full engine compatibility, or in Azure SQL Managed Instance for near-100% SQL Server engine parity. ASP.NET applications run on Azure App Service or IIS-configured VMs without code changes. Active Directory integrates with Entra ID through hybrid identity configuration — your on-premises AD forest stays authoritative while Entra ID provides cloud identity services. SSRS and SSIS run on SQL Server VMs. Your stack evolves at your pace, on your timeline, without forced re-platforming.More on the Managed Azure Operations page
- What is Azure for Government and do we need it?
- Azure Government is a physically separated set of Azure regions accessible only to US government entities and their partners — operated by screened US citizens, isolated from commercial Azure infrastructure. It provides the same Azure services within an environment that meets FedRAMP High, DoD IL2, CJIS, IRS 1075, HIPAA, and ITAR compliance requirements. State and local government agencies handling criminal justice data, federal tax information, or other controlled unclassified information typically require Azure Government. Municipal websites, public portals, and non-sensitive workloads can often run in commercial Azure regions. We assess your compliance requirements in Phase 1 discovery and recommend the appropriate Azure environment for each workload.More on the Managed Azure Operations page
- How does Microsoft licensing work through your CSP agreement?
- As a Microsoft CSP, we provision Azure subscriptions and Microsoft product licenses directly — your Azure consumption and Microsoft software licensing flows through our CSP agreement rather than a separate Microsoft EA or MPSA contract. For agencies already on an EA, we work with your Microsoft licensing team to assess whether CSP consolidation makes sense for your procurement structure. For agencies without an existing Microsoft volume licensing arrangement, CSP through eWay is often the simplest procurement path for both Azure and Microsoft software.More on the Managed Azure Operations page
- How do we procure eWay services as a government agency?
- We support multiple procurement paths. Direct engagement is available with standard government contract documentation. We are available through Carahsoft using their established government contract vehicles. Our SBA 8(a), MBE, DBE, and SBA Small Business certifications support set-aside and direct-award procurement. Contact us and we will identify the fastest procurement path for your organization's specific requirements and timeline.More on the Managed Azure Operations page
- Can you manage our Azure costs — not just our infrastructure?
- Yes. FinOps is a standing component of every managed engagement. Our monthly governance cycle includes an Azure cost optimization review: Reserved Instance opportunities, Azure Hybrid Benefit application for existing Windows Server and SQL Server licenses, VM and database rightsizing, idle resource elimination, and storage tier optimization. Azure Hybrid Benefit alone can reduce Windows Server and SQL Server VM costs by up to 40% for agencies with existing Software Assurance coverage — and it is one of the most consistently overlooked savings opportunities in government Azure environments.More on the Managed Azure Operations page
Category
Services
Managed WebOps and the operating model that holds it together.
Managed WebOps
Continuous operational ownership of CMS platforms and cloud infrastructure under defined SLAs.
Managed WebOps- What is Managed WebOps?
- Managed WebOps is a model where a single partner takes continuous operational responsibility for your entire digital platform — infrastructure, CMS, applications, and integrations. Unlike traditional hosting or development, Managed WebOps does not end at launch. It is an ongoing operating model with defined SLAs and human accountability for outcomes.More on the Managed WebOps page
- How is this different from managed hosting?
- A managed hosting provider gives you servers and basic uptime monitoring. Managed WebOps covers the full stack — infrastructure, CMS application layer, custom plugins and integrations, performance, security, and ongoing optimization. If your Drupal module causes a performance problem, we find it and fix it. A hosting provider opens a ticket.More on the Managed WebOps page
- What does an SLA actually cover?
- Our SLAs cover uptime availability, incident response times by severity level, patch deployment timelines for security vulnerabilities, and performance benchmarks. Every engagement has a defined scope with documented escalation paths — not vague 'best effort' commitments.More on the Managed WebOps page
- Do you support all three CMS platforms simultaneously?
- Yes. If your institution uses Cascade CMS for marketing, Drupal for a department portal, and WordPress for a microsites program, we can manage all three under a single engagement — with consistent operations, reporting, and a dedicated team that knows your full environment.More on the Managed WebOps page
- How do you handle security vulnerabilities and patches?
- We maintain a patching schedule aligned to our SLA — critical CVEs are addressed within defined windows, standard patches on a regular cycle. We test before deploying, maintain rollback capability, and document every change. You receive monthly reporting on patch status across your environment.More on the Managed WebOps page
Cloud Operations
AWS and Azure environments architected and operated for public-sector institutions. Migration via the AWS 7Rs framework, FedRAMP-aligned baselines, and ongoing cost discipline.
Cloud Operations- We're already on AWS. Do we have to switch providers to engage you?
- No. We operate AWS environments that we built ourselves and AWS environments built by previous vendors or your internal team. Onboarding starts with a Platform Assessment to document the current state, identify the operational and security gaps, and bring it to our operating standard. Most engagements start this way.More on the Cloud Operations page
- How is Cloud Operations different from your Managed WebOps service?
- Cloud Operations is the cloud infrastructure layer specifically: AWS or Azure environment, architecture, security baseline, identity, networking, cost discipline. Managed WebOps is the broader engagement that wraps cloud operations plus the CMS, applications, and integrations on top. Many clients start with Cloud Operations and expand to full WebOps as the relationship matures.More on the Cloud Operations page
- AWS or Azure: which should we choose?
- It depends on your existing investment. If you have a Microsoft stack (Active Directory, SQL Server, Dynamics, .NET applications), Azure is often the better fit for keeping things consolidated. If you're starting fresh or run primarily on Linux or open-source web platforms, AWS is usually the right call. Most of our clients run on AWS but we operate on both, and some clients run a mixed environment. We assess in Phase 1 and recommend based on your situation, not our preference.More on the Cloud Operations page
- How do you handle FedRAMP requirements?
- We operate AWS environments using FedRAMP-aligned baselines for state and local agencies that don't require full FedRAMP authorization (which is reserved for federal workloads on FedRAMP-authorized platforms like AWS GovCloud). For agencies that do require FedRAMP authorization, we work with AWS GovCloud or Azure Government. The right answer depends on whether you're federal-regulated or following federal best practices.More on the Cloud Operations page
- What does cost optimization look like in practice?
- Right-sizing on a quarterly cadence (we look at the workloads and trim what's overprovisioned). Reserved instances or savings plans where the workload is predictable. Idle resource cleanup. Tag-based cost reporting so you can see where the spend is going by department or project. We don't earn margins on cloud markup; the discipline is in the operations, not the resale.More on the Cloud Operations page
- Can you help with migration from on-premise or another cloud?
- Yes, this is a core service. We use AWS's 7Rs framework (Refactor, Replatform, Repurchase, Rehost, Relocate, Retain, Retire) to assess each workload and recommend the right strategy per workload. Most migrations end up combining three or four strategies. We plan the cutover, manage the migration, and continue operating the environment afterward.More on the Cloud Operations page
Website & CMS Services
End-to-end CMS platform delivery and operation across Cascade, Drupal, and WordPress for institutions that publish at scale.
Website & CMS Services- We're already running Cascade (or Drupal, or WordPress). Do we have to switch?
- No. We operate the CMS you already chose. Most engagements start by taking over an environment that someone else built. We assess the platform's current state, document the gaps, and bring it to our operating standard. Migration is only on the table if the platform is genuinely the wrong fit, and that's a decision we make jointly.More on the Website & CMS Services page
- How is this different from a CMS implementation agency?
- Implementation agencies build the platform and hand it off. We build it (or take over what someone else built) and operate it after launch. Most of our long-term clients started with another agency for the build. We came in to operate what they delivered, and stayed.More on the Website & CMS Services page
- How does this differ from your Managed WebOps service?
- Website & CMS Services covers the CMS platform layer specifically: implementation, content architecture, accessibility, governance, and ongoing CMS operations. Managed WebOps is the broader engagement that wraps the CMS plus the cloud infrastructure underneath plus applications and integrations. Many clients start with one and expand to the other as the relationship matures.More on the Website & CMS Services page
- Do you do design and branding work?
- No, but we work alongside agencies that do. Most of our clients have a design or brand partner already. We coordinate with them, implement their design system, and operate the platform that ships their design. If you don't have a design partner yet, we can recommend several we've worked well with.More on the Website & CMS Services page
- What about content writing and editorial?
- We don't write your content. Your editorial team or your content agency does that. We make sure the publishing environment works well for them: governance, workflows, accessibility tooling, multi-site templates, and the kind of CMS that doesn't get in the way.More on the Website & CMS Services page
- We're considering migrating to a different CMS. Can you help us decide?
- Yes. We start with an assessment of where you are and what you need. The decision usually comes down to publishing model (centralized vs decentralized), accessibility requirements, integration needs, multi-site complexity, and budget. Sometimes the right answer is to migrate. Often the right answer is to operate the CMS you already have, properly.More on the Website & CMS Services page
Application Modernization
Custom application rebuild and system integration for institutions running stacks they have outgrown or systems that were never designed to talk to each other.
Application Modernization- We have a custom application that no one on our team can maintain anymore. Can you take it over?
- Yes. Most of our application engagements start with a system the original developer no longer supports. We assess the current state, document what exists, and either modernize what's there or rebuild it depending on what actually makes sense. We then operate the application after launch.More on the Application Modernization page
- We need Cascade to talk to Banner (or Drupal to Salesforce, etc.). Can you build that integration?
- Yes. CMS-to-SIS integrations are one of the two specific things this service is for. We design the API contract, build the integration layer, handle data synchronization and identity federation, and operate the integration on the same managed engagement model we apply to platforms.More on the Application Modernization page
- How does this differ from your Cloud Operations service?
- Cloud Operations is the AWS or Azure environment your applications run on: networking, IAM, scaling, monitoring, security baseline. Application Modernization is the application layer itself: the code, the data model, the integrations between systems. Many engagements use both services together.More on the Application Modernization page
- Will you operate the application after you build it?
- Yes. Application Modernization engagements transition into ongoing application operations under a managed services contract. The team that builds your application is the team that operates it. Same engineers, same architects, year over year.More on the Application Modernization page
- We are stuck on an old stack. Do we have to rewrite everything?
- Not necessarily. Sometimes the right answer is same-stack modernization (ASP.NET WebForms to ASP.NET Core, for example). Sometimes it is stack migration to something better suited to the work. We assess and recommend based on the application's actual constraints, not based on which stack we prefer.More on the Application Modernization page
- What about third-party APIs and webhooks?
- We design and operate API gateways, webhook receivers, and event-driven integrations. We treat them as production systems, not as one-off scripts. Versioning, monitoring, replay, retries, and idempotency are part of the design from the start.More on the Application Modernization page
Accessibility Compliance
WCAG 2.1 AA audits, remediation, and continuous compliance for Title II, Section 508, and Section 1557. One-time remediation, ongoing operational discipline, or both.
Accessibility Compliance- What does Title II of the ADA require, and which entities does it apply to?
- Title II of the ADA, under the DOJ rule finalized in April 2024, requires WCAG 2.1 Level AA conformance for all public-facing web content and mobile apps operated by state and local government entities and the entities they fund or contract with. The conformance deadline is April 24, 2026 for entities with populations of 50,000 or more, and April 24, 2027 for smaller entities and special district governments. The rule covers public agency websites, higher education institutions that receive state or local funding, public hospitals, public libraries, and many nonprofits operating government-funded programs. If you are public-sector or public-sector-adjacent, the rule almost certainly applies to you.More on the Accessibility Compliance page
- How is Title II different from Section 508 and Section 1557?
- Section 508 is the federal procurement rule. It requires accessible information and communication technology in federal agencies and entities receiving federal funds. WCAG 2.1 AA is the technical baseline. Title II of the ADA covers state and local government entities and entities operating government programs, with the same WCAG 2.1 AA technical baseline. Section 1557 of the Affordable Care Act prohibits discrimination in health programs receiving federal financial assistance and requires meaningful access for people with limited English proficiency along with accessible communications for people with disabilities. Many health departments, federally qualified health centers, public hospitals, and academic medical centers receiving federal funding are subject to Section 1557 and Title II simultaneously. WCAG 2.1 AA is the technical standard that satisfies the accessibility requirements of all three frameworks. The differences are in scope, enforcement, and the documentation a regulator will ask for.More on the Accessibility Compliance page
- Why does a one-time audit not solve the problem?
- An audit captures the state of the platform on the day it was tested. The minute a content editor publishes a new page, adds a new image without alt text, or embeds a third-party widget that ships with accessibility issues, your audit no longer reflects reality. We treat accessibility as a continuous operational discipline, not a launch audit. The audit closes the existing list. The continuous program prevents the next list from accumulating. Most institutions discover within six months of a one-time audit that they are back to a backlog they cannot keep up with. The standalone audit is a starting point. It is not a finish line.More on the Accessibility Compliance page
- What does an accessibility audit actually include?
- Automated scanning across every public template and content type. Manual testing against WCAG 2.1 AA success criteria by an accessibility specialist who reads the spec, not a tool. Assistive-technology testing with screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, voice control, and zoom/magnification scenarios. Document accessibility review for PDFs, forms, and downloadable assets. A prioritized findings report that distinguishes blockers from polish items, tied to the specific WCAG criterion each finding violates. Remediation guidance written for the engineers who will fix it, not as generic checklist items. We deliver this as evidence your audit committee or your information security officer can reference, not as a screenshot of a Lighthouse report.More on the Accessibility Compliance page
- Do you remediate document accessibility (PDFs, forms, downloadable assets)?
- Yes, and document accessibility is the most commonly overlooked gap in institutional websites. A site that conforms to WCAG 2.1 AA at the template level can still be effectively inaccessible because the PDFs, board minutes, application forms, and policy documents linked from it are untagged, unstructured, or scanned images. We remediate document accessibility as part of the audit and continuous compliance program: PDF tagging, reading-order correction, form-field labeling, alternative-format provision, and editor workflows that prevent inaccessible documents from being uploaded in the first place.More on the Accessibility Compliance page
- How do you handle accessibility for content editors who publish daily?
- Editor governance is where most accessibility programs fail. We design CMS-level guardrails into the publishing workflow: required alt-text on image upload, heading-structure validation, link-text quality checks, and inline accessibility feedback in the authoring experience. We train your content team on the editorial decisions that affect accessibility (image alt text, link context, heading hierarchy, video captions, plain-language writing). Recurring office hours and a defined escalation path for accessibility questions keep the program operational beyond the initial training. The goal is a publishing environment where content editors do not have to be accessibility experts to publish accessible content.More on the Accessibility Compliance page
- Can you take over accessibility work from a previous vendor?
- Yes, and this is a common engagement starting point. We assess what was delivered, document the actual current state of the platform (which often differs from what the previous vendor reported), identify the gaps between the previous remediation and current WCAG 2.1 AA conformance, and bring the platform to our continuous-compliance operating standard. We have inherited environments where the prior vendor closed an audit by suppressing automated-scan findings rather than fixing them. We do not work that way, and we will tell you honestly what we find.More on the Accessibility Compliance page
- What conformance documentation do you provide for our audit committee or general counsel?
- Quarterly conformance reports tied to WCAG 2.1 AA success criteria. The audit baseline and the remediation evidence for each closed finding. Editor governance documentation showing the controls in place to prevent regression. Automated-scan results across all public surfaces with trend lines. Manual testing logs by an accessibility specialist. The OCR-complaint response posture documentation if your general counsel asks how the platform would defend against a complaint. We design this evidence pack so it satisfies the people who will read it (your audit committee, your CISO, your general counsel, your accessibility coordinator), not as a generic compliance binder that nobody reads until a regulator shows up.More on the Accessibility Compliance page
- Do you support accessibility in CMS templates and design systems, not just remediation of existing pages?
- Yes. Accessibility is not a launch deliverable. Every new page template, every new component, every new content type is a new accessibility surface. We work with your design and front-end teams (or ours) to build WCAG 2.1/2.2 AA conformance into the design system at the component level: color contrast, focus states, keyboard interactions, ARIA implementation, and motion preferences. New components ship with accessibility test coverage. Design-system updates do not regress accessibility because regressions are caught in the development pipeline, not in production.More on the Accessibility Compliance page
- Is there a safe harbor or extension on the Title II deadline?
- The DOJ rule provides limited exceptions (archived content, preexisting conventional electronic documents not used for current programs, third-party content not under the public entity's control under specific conditions, and individualized password-protected content). These exceptions are narrow and not a safe harbor for an inaccessible primary platform. There is no general extension. The honest answer is that the deadline is real, the enforcement mechanism (OCR complaints, DOJ investigations) is real, and the institutions that have not started are running out of room. We will tell you what the conformance path looks like from where you are, including the realistic timeline. We do not sell a fast remediation that we cannot actually deliver.More on the Accessibility Compliance page
Category
Solutions by Industry
Government, higher education, healthcare, and nonprofit engagements.
Government
Government buyer questions across the buying journey: compliance and procurement experience, leadership transition continuity, multi-agency governance, ongoing engagement reality, disaster surge response, security review documentation, contract vehicle structuring, and exit strategy.
Government solutions- You work with counties and state agencies. Do you have experience with the specific compliance and procurement requirements we operate under?
- Yes. We hold SBA 8(a) certification and we are available through Carahsoft for state and local agency procurement. Our infrastructure on AWS and Azure is architected to align with NIST 800-53 controls, and we provide the documentation a state CISO will request as part of a security review. We have completed vendor security questionnaires for state and county agencies in eleven states. The procurement realities, sole source justifications under 8(a), cooperative purchasing thresholds, multi-year base periods with option years, are familiar territory rather than surprises that extend timelines.More on the Government page
- Our agency has gone through two CIO transitions in three years. How do you maintain continuity when our internal leadership changes?
- Our team's knowledge of your platform does not leave when your internal leadership changes. We maintain platform documentation, architecture decisions, integration contracts, and the historical reasoning for non-obvious configurations independently of your internal team. When a new CIO arrives, whether from a political transition or a career move, the next conversation does not start from scratch. The platform continuity is what survives the political cycle. Most of our long-term government engagements have outlasted at least one administration change with the same engagement manager and engineering team in place.More on the Government page
- Our web presence spans eleven agency sites with different content teams, different brand requirements, and different levels of technical capability. How do you govern that without creating a bottleneck?
- Multi-agency environments are governance problems disguised as technical problems. The governance answer is a publishing workflow that allows agency editorial autonomy on local content while enforcing institutional standards centrally: accessibility, security, brand framework compliance. The technical answer is a multi-site CMS architecture (typically Drupal) with shared design system, federated content models, and role-based access that maps to actual organizational structures. We design both together with your central communications team and the agency communications leads, and we operate the result. Each agency publishes independently without breaking the other agencies' experience or violating the standards your central office is responsible for enforcing.More on the Government page
- Our last vendor was responsive during the project and then became harder to reach after go-live. What does the ongoing engagement actually look like?
- The ongoing engagement is the engagement. We do not have a project mode and a maintenance mode with different teams and different responsiveness. The same engagement manager, the same engineers, and the same architects who deliver the implementation operate the platform afterward under defined SLAs. The cadence: continuous monitoring with automated alerting, weekly tactical syncs, monthly governance reviews documenting performance and security posture, quarterly architecture reviews surfacing what should be modernized next. When you need to reach us, you reach the engineer who knows your environment, not a tier-one queue.More on the Government page
- We have a disaster management exercise coming up and our emergency communications plan depends on the website. How does your platform handle an unplanned traffic surge during a declared emergency?
- The platform is architected for unplanned surges, not just predicted ones. Auto-scaling infrastructure on AWS or Azure responds to traffic increases automatically without manual intervention. CDN configuration is tuned for the publishing patterns your communications team uses during emergencies, multiple agencies pushing critical content simultaneously to a public-facing platform. The on-call engineer is available within fifteen minutes of an unexpected event, not the next business day. We test the platform against the historical surge pattern for the relevant cycle before the event, and we monitor through the window with the engineer who built the architecture on call. For declared emergencies that arrive without warning, that engineer responds immediately. Your emergency communications plan does not depend on a vendor opening a ticket.More on the Government page
- Our information security officer is going to ask for documentation of your security controls. What can you provide and how quickly?
- We provide NIST 800-53 aligned controls documentation, the security architecture documentation for the workloads we operate on AWS and Azure, our incident response procedures, our patch management cadence, our data handling practices, and our penetration testing cadence. Most state CISO offices receive these materials within three to five business days of request. We have been through agency-level security reviews in multiple states and we know what the typical questionnaires ask, so the first time we hand documents to your information security officer should not be the first time we have done it for an agency at your scale.More on the Government page
- We are required to competitively bid contracts above a certain threshold. How have other agencies structured engagements with you to fit within their procurement requirements?
- Several paths work depending on your jurisdiction's thresholds and your procurement office's preferences. SBA 8(a) sole-source awards under the threshold for eligible agencies. Direct engagement under standard government managed services SOW templates. Carahsoft for both AWS-related and broader managed services components. Cooperative purchasing agreements where your jurisdiction is a member of a cooperative. Statement of work language that accurately describes managed services as a continuous operational engagement rather than a project deliverable, which sometimes requires educating procurement offices that are more familiar with traditional vendor contracts. We have navigated these conversations before and we will work with your procurement office on the structure that fits your rules.More on the Government page
- What happens if we need to transition away from eWay at the end of a contract term?
- The platform documentation, the architecture decisions, the integration contracts, and the operational runbooks are documented during the engagement, not at the end of it. If you transition to another vendor or bring operations in-house, the next team has what they need to take over without rebuilding institutional knowledge. We provide knowledge transfer support during the transition period as part of the engagement, not as an extra-cost add-on. Government procurement requires this and our practice supports it. The platform stays operational through the transition. We do not hold institutional knowledge as leverage.More on the Government page
Higher Education
Higher-ed buyer questions across the buying journey: design partnerships, multi-year engagement realities, multi-campus governance, faculty senate, vendor transitions, and HECVAT.
Higher Education solutions- Can you work with our existing design agency or brand firm?
- Yes. Most of our higher-ed engagements involve a partner agency that owns the brand, the design system, or the campaign creative. We implement what they design and we operate the platform that ships their work. We do not try to replace the relationship you already have with a brand or design firm. If you do not have one, we can recommend several we have worked well with.More on the Higher Education page
- What does year three look like versus year one?
- Year one is implementation, onboarding, and stabilization. By the end of year one your platform should be measurably more reliable than when we started, and your team should have stopped being on call for things they shouldn't be. Year three is when the engagement compounds. The architecture is well-documented, the operational cadence is established, and the platform has survived at least one accreditation cycle, multiple admissions seasons, and likely a leadership change. The team you started with is the team you still work with. Most of our long-term clients are in year four or five with the original engagement manager.More on the Higher Education page
- Our web team has high turnover. What happens to institutional knowledge when our people leave?
- Our team's knowledge of your environment does not leave when your staff does. We maintain platform documentation, architecture decisions, integration contracts, and the historical reasoning for non-obvious configurations independently of your internal team. When your web director leaves, the next one does not have to discover from scratch why a particular Cascade asset factory was configured the way it was. The institutional knowledge stays with the engagement, not with the people who happen to be there at any given moment.More on the Higher Education page
- How do you handle multi-campus governance where each campus has its own communications team?
- Multi-campus environments are governance problems disguised as technical problems. The technical answer is multi-site CMS architecture with a shared design system and federated content models. The governance answer is a publishing workflow that allows campus autonomy on local decisions and central control on institutional standards. We design both together with your central communications team and the campus communications leads, and we operate the result. The flagship and the regionals can publish independently without breaking each other's experience or violating institutional brand standards.More on the Higher Education page
- How do you navigate faculty senate involvement in web governance decisions?
- Faculty senate involvement in academic department web changes is a real constraint at most universities. We have been in projects where a proposed change to academic department template structure required faculty senate review, and where the timeline for that review was longer than the timeline for the change itself. The way we navigate it is by treating the faculty senate as a stakeholder we plan around, not an obstacle we route around. We surface decisions that require faculty input early, we provide the documentation that the senate review needs, and we structure the work in phases that do not stall when the senate calendar slows everything down.More on the Higher Education page
- What happens to our CMS integrations when we change a core campus system?
- Every integration that connects the CMS to the SIS or the CRM has to be re-evaluated when one of those systems changes. A migration from Banner to Workday Student, a CRM swap from Salesforce to TargetX, an SSO change. Each one breaks integrations that were built against the previous system's API contracts. The way we handle this is by treating the integration layer as its own deliverable with versioned contracts and abstraction layers. When the underlying system changes, we modify the integration layer rather than rebuilding the integration from scratch. It does not eliminate the work, but it limits the blast radius and the timeline.More on the Higher Education page
- How do you handle the transition from our current vendor?
- Transitions from an existing vendor are part of most of our engagements. We start with a Platform Assessment to document the current state of your infrastructure, your CMS configuration, your integration contracts, and your operational gaps. We identify what we will keep, what we will rebuild, and what we will deprecate. We plan the cutover with your team and with the outgoing vendor where they are willing to cooperate. The most common outcome is a 90-day transition where we run in parallel with the outgoing arrangement before taking over fully. Your platform does not go down during the handoff.More on the Higher Education page
- Do you have a completed HECVAT?
- Yes. We maintain a current HECVAT and we provide it at any stage of your procurement process. Most institutions request it during late evaluation or at the start of contracting. We can provide it earlier if your information security officer wants to review before the engagement scope is finalized. The HECVAT covers our security posture for the workloads we operate on AWS and Azure, our data handling practices, and our compliance with the controls higher-ed institutions typically require.More on the Higher Education page
Healthcare
Healthcare buyer questions across the buying journey: PHI scope, BAA execution, EHR boundary (Epic, Cerner), Section 1557 vs Title II, post-breach security review, public health emergency surge, M&A integration, and vendor transition.
Healthcare solutions- You manage healthcare web platforms. Does that mean you have access to patient data?
- No. eWay operates the web platform layer. Our platforms are designed so that PHI does not transit through or reside in the CMS. Patient portal integrations connect to your EHR or patient data systems through APIs that keep PHI inside your covered systems. The web layer handles the session, the authentication handoff, and the user interface. It does not see the data behind it. That boundary is architectural, not just policy. We design every healthcare engagement so the web platform stays outside the PHI scope your covered entity infrastructure is already responsible for.More on the Healthcare page
- Do you sign a Business Associate Agreement?
- Yes. The BAA is a standard part of our healthcare engagement process, not a separate legal negotiation that has to be renegotiated each time. The agreement covers the limited operational context in which our platform operations could be adjacent to PHI, the security controls that govern that context, and the breach notification process if scope is ever materially expanded. We execute the BAA before the engagement begins. If your legal team has a preferred BAA template, we will work from yours rather than insisting on ours.More on the Healthcare page
- We use Epic for our patient portal and Cerner for clinical data. What does your engagement touch and what does it not touch?
- We do not implement, configure, integrate within, or manage Epic, Cerner, or any other EHR system. The web platform we operate sits in front of these systems and connects to them through published APIs and integration standards. The integration we build and maintain is the connection between the patient-facing web experience and the authentication or scheduling layer the EHR exposes. What is behind that layer (clinical data, billing records, care plans, encounter notes) is entirely outside our scope and always has been. Your EHR vendor and your clinical IT team own that surface. We own the web platform that sits on top of it.More on the Healthcare page
- What is the difference between Section 1557 and Title II, and how does your platform address both?
- Section 1557 of the Affordable Care Act prohibits discrimination in health programs receiving federal financial assistance and requires meaningful access for people with limited English proficiency along with accessible communications for people with disabilities. Title II of the ADA requires accessible digital services for entities that are government entities or that operate government programs. Many health departments, federally qualified health centers, public hospitals, and academic medical centers receiving federal funding are subject to both simultaneously. The web platform addresses both through WCAG 2.1 AA conformance as the technical standard that satisfies the accessibility requirements of each framework, plus language access considerations in the content modeling and UX design layer for Section 1557 (translation workflows, language toggles, alternative format support).More on the Healthcare page
- We had a ransomware incident last year that affected several systems. Our board is now asking harder questions about every vendor we bring in. What does your security documentation look like?
- We provide NIST 800-53 aligned controls documentation, the security architecture documentation for the workloads we operate on AWS and Azure, our penetration testing cadence, patch response windows by severity level, our incident response plan, our data handling practices, and the specific controls that govern our access to your web platform environment. This documentation is available at any stage of the procurement process, not only after contract execution. Your information security officer should not have to wait until the SOW is signed to evaluate our posture. On the post-breach concern specifically: our web platform engagement is scoped to the web layer and designed to minimize the attack surface your team is responsible for monitoring, not expand it. We do not introduce new privileged access paths into your covered systems or your EHR environment.More on the Healthcare page
- How does your platform handle a traffic surge during a public health emergency or a community health event?
- The platform is architected for unplanned surges, not just predicted ones. Auto-scaling infrastructure on AWS or Azure responds to traffic increases automatically without manual intervention. CDN configuration is tuned for the publishing patterns your communications team uses during emergencies, multiple stakeholders pushing critical content simultaneously to a public-facing platform that is suddenly carrying ten times its normal traffic. The on-call engineer is available within fifteen minutes of an unexpected event, not the next business day. We test the platform against the historical surge pattern for relevant events before they happen, and we monitor through the window with the engineer who built the architecture on call. The COVID-19 information page that went down during a surge announcement, the urgent care wait times page that was unavailable during a flu season spike: those failures were not unavoidable. They were preventable, and the platform we operate is designed to prevent them.More on the Healthcare page
- We are in the middle of integrating two health systems after a merger. We have three separate web presences, two CMS platforms, and a governance model that does not yet exist. Can you help with that?
- Yes, and post-merger digital integration is one of the more common engagement starting points in healthcare right now. The technical work is real: two CMS platforms to be rationalized, content models to be merged or rebuilt, integration contracts to be re-evaluated against the new system landscape, brand standards to be harmonized. What matters more is the political work alongside it. Two health systems that just merged have two communications teams, two brand histories, two sets of stakeholder expectations, and two sets of patient-facing content that need to become one coherent presence. We approach platform consolidation with an assessment process that surfaces the technical and political dimensions together, a migration plan that respects the timeline of the broader merger integration program, a governance model designed jointly with both communications teams, and a phased consolidation that does not disrupt patient access during the transition. We have done this. We will not pretend it is purely a technical migration problem.More on the Healthcare page
- Our last web platform partner built something we could not maintain without them. What happens if we need to transition away from eWay?
- The platform documentation, the architecture decisions, the integration contracts, and the operational runbooks are documented during the engagement, not at the end of it. If you transition to another vendor or bring operations in-house, the next team has what they need to take over without rebuilding institutional knowledge from scratch. We provide knowledge transfer support during the transition period as part of the engagement, not as an extra-cost add-on. The platform is built on standard open source and cloud technologies, no proprietary lock-in, no custom build that only our engineers understand. We do not hold institutional knowledge as leverage. Your platform stays operational through the transition. We will hand off cleanly because that is the engagement model we sell, not just the engagement model we describe in our proposal.More on the Healthcare page
Nonprofits
Nonprofit buyer questions across the buying journey: open source vs proprietary CMS, AWS Nonprofit Credit Program, vendor data agreements, CRM integration scope, campaign-ready engagement, predictable cost, vendor transition, and multi-affiliate consolidation.
Nonprofit solutions- Should we use a proprietary CMS, or stick with WordPress or Drupal?
- For most nonprofits, WordPress or Drupal is the right answer. Proprietary CMS platforms charge licensing fees that can run thousands of dollars per year, money that nonprofits cannot afford to spend on software when it could fund programs, staff, or campaigns. WordPress and Drupal are free and open source with global communities of contributors and a large pool of available developers and operators. The hidden cost of a proprietary CMS is not just the licensing fee, it is the vendor lock-in: when the vendor raises prices, sunsets a feature, or changes the licensing terms, you have limited recourse. The case for a proprietary CMS exists for very specific scenarios, but it is rarely the right choice for a 501(c)(3) operating on grant funding and donor revenue. We will tell you honestly which platform fits your situation.More on the Nonprofits page
- Are we eligible for the AWS Nonprofit Credit Program, and how does that affect our hosting cost?
- Most 501(c)(3) organizations are eligible for the AWS Nonprofit Credit Program, which provides annual cloud credits for AWS infrastructure. The credits significantly offset hosting costs and in many cases cover most or all of the AWS spend for nonprofit web platforms. We help eligible nonprofits apply for and renew their program enrollment, and we architect AWS environments to make best use of the credit allocation: right-sizing compute, using cost-aware service tiers, and optimizing storage and network spend so the credits stretch as far as possible. The credits do not cover our managed services fee, but the underlying AWS infrastructure cost is dramatically lower than what a commercial nonprofit would pay for equivalent hosting.More on the Nonprofits page
- What kind of data agreement do you sign? We have donor data and constituent records that we need to protect.
- We sign data processing agreements as part of any engagement involving access to donor records, constituent data, or other personally identifiable information. The agreement covers what data we touch, what controls govern that access, what breach notification process applies, and what happens to the data at the end of the engagement. Most nonprofits do not require a formal BAA (which is a HIPAA-specific instrument), but they do need vendor data agreements that address state privacy laws, donor record protection, and the data processor obligations under CCPA, VCDPA, and similar state regulations. If your legal team has a preferred data agreement template, we will work from yours rather than insisting on ours. The agreement is executed before the engagement begins.More on the Nonprofits page
- We use Salesforce NPSP (or Blackbaud, or Classy). What does your engagement touch and what does it not touch?
- We do not implement, configure, or manage Salesforce NPSP, Blackbaud Raiser's Edge, Luminate Online, or any other donor management system. Those platforms are owned by your development team or by a Salesforce or Blackbaud implementation partner. What we do is the integration layer between your web platform and your CRM: building and maintaining the connection that takes online donations, event registrations, advocacy actions, and email signups from your website into your CRM through published APIs. The integration is operated under our managed engagement, not handed off as a one-time project. When your CRM upgrades or changes a field structure, we update the integration. Your donor data stays in your CRM. We do not touch the donor records themselves.More on the Nonprofits page
- Giving Tuesday and year-end campaigns are the most important fundraising moments of our year. What does your engagement look like during those windows?
- We treat Giving Tuesday and year-end as named operational events with pre-event readiness reviews, dedicated on-call coverage during the window, and the engineer who built your platform on call rather than a generic support queue. Before the campaign launches, we load-test the donation pages against historical traffic patterns, validate payment gateway integrations, warm CDN caches, and walk through your team's escalation path. During the window, we monitor proactively, respond to alerts in under fifteen minutes, and resolve issues without your team having to manage infrastructure during the moments that matter most. Year-end planning starts in October. Giving Tuesday planning starts in late summer. Emergency fundraising appeals (disaster response, advocacy moments) get the same operational treatment with shorter notice.More on the Nonprofits page
- Our budget cycle does not handle surprise invoices well. How is your pricing structured?
- Our pricing is structured as monthly managed services fees under an annual contract, predictable from the day the engagement begins through the end of the fiscal year. There are no per-user fees, no usage-based scaling charges, and no surprise invoices during peak campaigns. The AWS or Azure infrastructure cost is separate and runs on your AWS or Azure account, often offset substantially by the AWS Nonprofit Credit Program for eligible organizations. We renegotiate the contract at the annual renewal point with full visibility into next year's scope and cost before the current year ends. Your finance team plans against a fixed line item, not a variable expense that fluctuates based on traffic or platform usage.More on the Nonprofits page
- What happens if we need to transition away from eWay at the end of a contract term?
- The platform documentation, the architecture decisions, the integration contracts, and the operational runbooks are documented during the engagement, not at the end of it. If you transition to another vendor or bring operations in-house, the next team has what they need to take over without rebuilding institutional knowledge from scratch. We provide knowledge transfer support during the transition period as part of the engagement, not as an extra-cost add-on. The platform is built on standard open source and cloud technologies, no proprietary lock-in, no custom build that only our engineers understand. We do not hold institutional knowledge as leverage. Your platform stays operational through the transition.More on the Nonprofits page
- We are part of a parent organization with multiple affiliates. How does your engagement handle a multi-org or affiliate structure?
- Multi-affiliate and parent-organization structures are common in the nonprofit sector: national organizations with regional or local affiliates, foundation networks with grantee structures, advocacy organizations with chapters. The technical work is multi-site CMS architecture with shared design system and federated content models that allow each affiliate to maintain editorial autonomy within central brand and accessibility standards. The political work alongside it matters more. Each affiliate has its own director, its own donor base, its own local stakeholders. We design platform consolidation engagements that respect that political reality. When two organizations merge or a national parent absorbs an affiliate, we handle the platform consolidation work alongside the broader integration program, not as a separate technical project.More on the Nonprofits page
Did not find what you were looking for?
Schedule a 30-minute conversation.
Most institutional questions are easier to answer in conversation than to write down. We will scope your specific situation, walk through your stack, and outline what an engagement could look like.
No commitment requiredResponse within 1 business dayTrusted by 100+ institutionsWe will not spam your inbox