DEV Community: Affix Center Softech Services Pvt. Ltd

A Staged Cloud Migration Checklist: Sequencing, Rollback and What to Monitor After

Affix Center Softech Services Pvt. Ltd — Tue, 20 Oct 2026 15:08:57 +0000

Lift-and-shift weekends make good stories when they work and painful ones when they don't. A staged migration is slower on paper but usually safer: you move a few workloads at a time, check them, and keep a tested way back.

Here is a practical checklist we use as a starting point.

1. Assess before you plan

Inventory every server, app and scheduled job, including the ones nobody remembers owning.
Map dependencies: which service calls which database, file share or API.
Mark workloads that cannot have downtime, and those with compliance rules on where data lives.
Decide per workload whether it belongs in private, public or hybrid cloud, based on compliance, performance and cost.

2. Plan sequencing and rollback together

Order moves so dependencies go first, or move tightly coupled pieces in the same stage.
For each stage, write the rollback steps: how traffic returns to the old system and how data written in the meantime is reconciled.
Agree on go / no-go checks before the window starts, not during it.

3. Move in stages

Migrate a small batch, validate data integrity, then run real traffic.
Keep the old environment intact until the stage is signed off.
Record every config change so the next stage is repeatable.

4. After go-live: monitor, back up, tune

Set up continuous monitoring for availability and performance from day one.
Configure backup and disaster recovery, then actually test a restore. An untested backup is a guess.
Harden security settings in the new environment and review them regularly.
Revisit sizing and cost once you have a few weeks of real usage data.

More detail: how Affix Center approaches cloud migration and server lifecycle management

Written by the team at Affix Center, an IT services company in Lower Parel, Mumbai.

Connecting a Legacy System to a New Web App: A Practical Integration Checklist

Affix Center Softech Services Pvt. Ltd — Tue, 13 Oct 2026 11:39:12 +0000

Most new business apps do not start on a blank slate. They have to talk to an old ERP, an accounting package, a government portal or a third-party service that nobody wants to touch. In product work for enterprises, SMEs and government bodies, weak integration and disconnected departments are among the most common problems we see, so integration deserves its own plan from day one.

Before you write any code

Map the systems and owners. List every system the new app must read from or write to, and who can approve changes on each side.
Decide where each piece of data lives. One system should be the source of truth for customers, another for invoices, and so on. Duplicated masters cause most sync bugs.
Pick the integration style per system. A clean REST API, a scheduled file export, or a database view. Older systems often only support the last two.

Design it so it can change

Keep integrations in their own module. An adapter layer between your app and each external system means a replacement later touches one module, not the whole codebase.
Expect failures. Add retries, timeouts and a queue for writes so a slow legacy system does not freeze your UI.
Log every exchange. When numbers do not match between two systems, request and response logs settle the argument quickly.

Ship it safely

Put integration tests in the CI/CD pipeline with stubbed versions of each external system, so a change on your side cannot silently break the link.
Test performance with realistic volumes, not ten sample records.
Treat credentials as secrets. Keep API keys out of the repo and give each integration the least access it needs.
Give managers a dashboard with role-based views of sync status, so problems are seen before users report them.

More detail: how Affix Center approaches API integration and product engineering

Written by the team at Affix Center, an IT services company in Lower Parel, Mumbai.

What a VAPT report should hand back to your dev team

Affix Center Softech Services Pvt. Ltd — Sat, 10 Oct 2026 06:34:52 +0000

A penetration test is only useful if developers can act on the result. A long PDF of scanner output does not help anyone ship a fix. Here is what a development team should expect from a vulnerability assessment and penetration test (VAPT), based on how the security team at Affix Center in Mumbai runs these engagements.

What gets tested

Infrastructure, applications and APIs, not only the public website
Secure configuration reviews of the systems the app runs on
Controlled penetration testing, so production is not put at risk

What you should get back

A risk-ranked report, so the team knows what to fix first
Remediation steps for each finding
Both an executive report and a technical report, because managers and developers need different detail
A retest after the fixes, to confirm they worked

Controls worth building in before the test

A secure development lifecycle
Authentication and authorisation on every API
Encryption at rest and in transit
Role-based access, with audit and compliance traceability

How often

Run VAPT at least once a year, and again after any major change to an application or to infrastructure.

If your organisation faces NIC or CERT-In empanelled security audits, plan time to fix the observations those audits raise. That work usually lands on the development team.

More detail on scope and process: Cyber Security and VAPT services by Affix Center

Written by the team at Affix Center, an IT services company in Lower Parel, Mumbai.

47-Day TLS Certificates Are Coming: What Ops Teams Should Automate Now

Affix Center Softech Services Pvt. Ltd — Mon, 05 Oct 2026 17:35:09 +0000

If you still renew TLS certificates by hand from a calendar reminder, the next three years will be rough. The CA/Browser Forum approved Ballot SC-081v3 in April 2025, and the maximum lifetime of publicly trusted certificates is being cut in stages.

The schedule

From	Maximum validity
15 March 2026	200 days
15 March 2027	100 days
15 March 2029	47 days

The window for reusing domain validation also shrinks, to 10 days by 2029. In practice that means about two renewals a year per certificate today and about eight a year by 2029. Manual renewal does not scale to that.

Quick answers

Do I need to replace my current certificates? No. They stay valid until they expire.
Are free certificates covered? Yes. The limits apply to all publicly trusted certificates.
What about apps that cannot use ACME? Put them behind a reverse proxy or load balancer that can, or plan an upgrade.

Where to start

Inventory every certificate: domain, where it is installed, issuer, expiry date and owner.
Give each certificate an owning team, not a single person.
Automate issue and renewal with the ACME protocol.
Add expiry monitoring that is independent of the renewal tool, with alerts at 30, 14 and 7 days.

Full guide with the six-step plan and the common mistakes: https://affixcenter.com/blog/ssl-certificate-validity-2026-renewal

Written by the team at Affix Center, a Mumbai-based IT services company. More on our IT operations and managed services.

SPF, DKIM and DMARC: Email Security Setup Guide

Affix Center Softech Services Pvt. Ltd — Fri, 25 Sep 2026 12:32:34 +0000

Originally published on the Affix Center blog.

Anyone can send an email that claims to come from your domain unless you tell the world's mail servers otherwise. Fake invoices, fake payment change requests and fake HR notices sent in a company's name are among the most common frauds Indian businesses face. This guide explains the three DNS records that stop most of this spoofing and how to put them in place without breaking your genuine email.

There is a second reason to act. Since February 2024, Google and Yahoo have required bulk senders (around 5,000+ messages a day to their users) to authenticate mail with SPF, DKIM and DMARC. Microsoft introduced similar rules for high-volume senders. Even if you send far less, missing records make it more likely that your quotations and invoices land in spam.

What SPF, DKIM and DMARC each do

SPF (Sender Policy Framework): a DNS record listing the servers allowed to send mail for your domain.
DKIM (DomainKeys Identified Mail): a digital signature added to every outgoing message, checked against a public key in your DNS.
DMARC: a policy that tells receivers what to do when a message fails SPF and DKIM, and where to send reports.

SPF and DKIM prove a message is authorised. DMARC ties them to the visible "From" address and enforces the result. You need all three.

Step 1: Inventory every system that sends your email

List every service that sends mail using your domain: Microsoft 365 or Google Workspace, ERP/accounting (invoices), HRMS/payroll (payslips), CRM and newsletter tools, website forms, helpdesk, and scanners or on-prem apps that relay mail. The finance team's invoicing tool is the one most often forgotten.

Step 2: Set up SPF correctly

v=spf1 include:spf.yourmailprovider.com include:mail.invoicetool.com -all

Only one SPF record per domain.
Stay within 10 DNS lookups (nested includes count).
-all rejects anything not listed; ~all soft-fails. Many teams start with ~all and rely on DMARC for enforcement.
Remove includes for tools you no longer use.

Step 3: Enable DKIM signing

In each sending service: generate a key (2048-bit where offered), publish the public key at the selector it gives you (e.g. selector1._domainkey.yourdomain.in), turn signing on, and check test headers for dkim=pass. Repeat for every sender.

Step 4: Publish DMARC and move to enforcement

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.in

Monitor with p=none and read the aggregate reports.
Fix every legitimate sender that fails (2-4 weeks).
Quarantine with p=quarantine.
Reject with p=reject: the goal.

For parked domains that never send mail, publish v=spf1 -all and a DMARC policy of p=reject.

Step 5: Test, document and maintain

Test after every change, keep a DNS change log, add SPF/DKIM to vendor onboarding, rotate DKIM keys, and restrict DNS access with MFA on your registrar.

Common mistakes

Stopping at p=none.
Multiple SPF records added by different vendors.
Forgetting that forwarding breaks SPF (so DKIM on every sender matters).
Overlooking subdomains.
No owner for DMARC reports.
Relying on authentication alone: lookalike domains and compromised accounts need other controls.

Full guide with FAQs: SPF, DKIM and DMARC setup guide on affixcenter.com