Search this site

Trading partners don't wait for your systems to catch up. A retailer sends an 850 purchase order in X12 format, a European supplier sends the equivalent in EDIFACT, and your ERP needs both translated, validated, and acknowledged within hours, not days. Informatica B2B Gateway exists to handle that translation layer, and this guide walks through how a certified implementation partner takes it from requirements to go-live. 1. Define the requirements Start by naming the actual document types the implementation needs to support. Most B2B Gateway rollouts center on four: the 850 Purchase Order, 810 Invoice, 856 Advance Ship Notice, and 997 Functional Acknowledgment. Map each trading partner to the standard they use, because this decision splits early. US retailers and distributors typically run X12; European and Asian trading partners typically run EDIFACT. Get this partner-by-partner list locked before configuration starts, since it drives every mapping decision downstream. 2. Configure the B2B Gateway Once requirements are set, configuration centers on the transport layer. AS2 is the default for most retail and distribution trading partners because it gives you signed, encrypted, non-repudiated delivery with a receipt (the MDN) built into the protocol. SFTP still shows up for smaller partners or legacy setups where AS2 certificates aren't worth the overhead. Each choice comes with its own partner profile setup: AS2 needs certificate exchange and endpoint configuration with the partner's AS2 station; SFTP needs credential provisioning and folder structure agreement. Get this settled per partner before you touch mapping. 3. Create and map EDI documents This is where the actual translation logic lives, and it's the step most implementations underestimate. Informatica's Hierarchy Mapper is the tool built for exactly this job: converting hierarchical EDI, XML, and JSON structures between formats without hand-coding the parent-child relationships that make EDI mapping hard in the first place. Pingahla has taken this exact step through a recent client engagement that replaced legacy PowerCenter DT (Data Transformation) code with Hierarchy Mapper's native IDMC approach, cutting a maintenance burden that had been accumulating for years. More on that in the Real-World Example section below. 4. Test the EDI transactions Testing means more than sending a document and confirming it arrived. The mechanism that actually proves a document was received cleanly is the 997 Functional Acknowledgment: a trading partner's system parses your outbound EDI, checks it against the agreed specification, and returns a 997 confirming acceptance or flagging specific segment errors. No 997 test cycle is complete until you've deliberately sent a malformed document and confirmed the gateway's error handling catches it before it reaches the partner. 5. Deploy the system Don't cut over your full trading partner list on day one. The pattern that keeps risk low is a phased rollout: pick one pilot partner, typically the one with the simplest document set and the most cooperative EDI team, run production traffic through them for one to two weeks, then use what you learn to scale to the rest of the partner list in waves. A single partner surfacing a mapping edge case is a fifteen-minute fix; fifty partners surfacing the same edge case simultaneously is an incident. 6. Monitor and maintain EDI failures are quiet by default. A malformed document, a missing 997, or a partner endpoint that silently stopped responding won't show up unless something is actively watching for it. The event-tracking framework built alongside the Hierarchy Mapper implementation above solves this by logging every document event, sent, received, acknowledged, or failed, into a queryable trail instead of leaving it buried in gateway logs. That visibility is what turns “EDI implementation” into “EDI operation,” and it's the difference between finding a problem in minutes versus finding it when a trading partner calls asking where their invoice went. Real-World Example Pingahla has carried this exact process through for enterprise clients modernizing legacy EDI flows, including a recent engagement replacing legacy PowerCenter DT code with Informatica's native Hierarchy Mapper inside B2B Gateway. The result cut maintenance overhead on the mapping layer while adding real-time transaction visibility the old setup never had. Read the full implementation story. If you're earlier in the evaluation process and want the fundamentals first, see what EDI is and why it matters. Frequently Asked Questions What is Informatica B2B Gateway used for? Automating EDI and non-EDI file exchange (X12, EDIFACT, CSV, XML) with trading partners: validating incoming documents, converting them to XML for backend systems, and generating outbound EDI from ERP or order-management data. Does B2B Gateway support both X12 and EDIFACT? Yes. Pre-built processing mappings validate and convert both standards, along with functional and technical acknowledgments back to the partner. How long does a typical B2B Gateway EDI implementation take? It depends on trading partner count and document complexity, but a phased rollout, pilot partner first, then scaling to the full partner list, is the standard pattern for keeping risk low during go-live. What's the difference between B2B Gateway and Hierarchy Mapper? B2B Gateway is the platform that manages partner onboarding, transport, and EDI processing end to end. Hierarchy Mapper is the specific IDMC component used inside that platform to convert hierarchical data (EDI, XML, JSON) between formats. It's what replaces legacy PowerCenter DT logic in modern implementations. Updated August 2026. This implementation pattern applies across current B2B Gateway and IDMC versions; specific transport and mapping details should be confirmed against your active Informatica release. Work with a certified Informatica IDMC partner: Talk to Pingahla

Cloudera's pricing and support terms have pushed migration onto the roadmap at most enterprises still running CDP or legacy CDH. Gartner's 2024 outlook put it plainly: more than 70% of enterprises running legacy Hadoop are expected to move to cloud lakehouse architectures by 2027. The decision to leave is rarely the hard part. The hard part is knowing what actually has to move, in what order, and what breaks if you skip a step. This guide covers the full path: how Cloudera's components map to Databricks, the tools built specifically for this migration, a realistic phase-by-phase plan, what it costs and how long it takes, and the mistakes that turn a three-month migration into a nine-month one. How Cloudera and Databricks actually differ Cloudera runs on a fixed cluster model: HDFS for storage, YARN for resource management, and a set of long-running services (Hive, Impala, Ranger, Oozie) that share that cluster whether or not they're all busy. You provision for peak load and pay for it around the clock. Databricks separates storage from compute. Data lives in cloud object storage (S3, ADLS, or GCS) as Delta Lake tables, and compute clusters spin up for a job and shut down when it's done. Unity Catalog handles governance across every workspace instead of per-cluster policy files. That separation is the reason the cost and scaling arguments for Databricks hold up, and it's also the reason migration isn't a lift-and-shift. Every layer of the stack has a different shape on the other side. Component-by-component mapping Cloudera's components map onto Databricks as follows: HDFS (distributed file storage on-cluster) becomes cloud object storage (S3, ADLS, or GCS) plus Delta Lake. Storage decouples from compute, and files convert to Delta format for ACID transactions and time travel. Hive Metastore (table and schema catalog) becomes Unity Catalog. The catalog becomes account-level instead of cluster-level, and a three-level namespace (catalog, schema, table) replaces the old two-level one. Hive / Hive LLAP (batch and interactive SQL) becomes Databricks SQL / Spark SQL. HiveQL syntax mostly carries over, but UDFs and SerDes often need rewriting. Impala (low-latency interactive SQL) becomes Databricks SQL with Photon. There's no separate query engine to maintain; one engine covers both batch and interactive workloads. Apache Ranger / Sentry (access policy and audit) becomes Unity Catalog access control. This isn't a 1:1 mapping; Ranger's fine-grained, resource-specific policies need to be re-modeled as Unity Catalog grants, often with a policy simplification pass first. Oozie (workflow scheduling) becomes Databricks Workflows (or Airflow). DAG definitions need to be rebuilt; Oozie XML doesn't convert automatically. YARN (cluster resource management) becomes Databricks cluster manager / serverless compute. Long-running shared clusters give way to job-scoped clusters that terminate on completion. Spark on YARN (distributed processing) becomes Spark on Databricks (with Photon). Spark code is largely portable; cluster configuration and tuning change substantially. The governance row is where most migration estimates go wrong. Teams that treat Ranger-to-Unity-Catalog as a policy export/import discover mid-project that Ranger's row- and column-level rules, tag-based policies, and per-service grants don't have a clean equivalent; they have to be redesigned, not translated. The tools built for this specific migration Databricks has shipped purpose-built tooling for exactly this move, which changes the “should we hand-roll scripts or buy a migration platform” calculus: UCX (Databricks Labs, open source) scans an existing Hive Metastore environment, inventories tables, views, jobs, permissions, and the teams that own them, and generates a readiness report before you touch anything. It also automates a meaningful share of the actual Hive-to-Unity-Catalog conversion. Lakebridge (Databricks, free) is built for legacy data warehouse and ETL migration specifically. Its Analyzer profiles the source environment and classifies each workload (table, view, job, stored procedure) by migration complexity, from low to very complex. Its Converter rewrites legacy SQL and ETL logic into Databricks SQL or Spark SQL. Its Validator reconciles source and target data for accuracy. Databricks' own figures put automation coverage at up to 80% of migration tasks; treat that as a vendor claim to validate against your own workload mix, not a guarantee. Hive Metastore Federation lets you keep the legacy metastore live while Unity Catalog governs new and migrated tables, which is what makes an incremental (“soft”) migration possible instead of forcing a single cutover weekend. The migration path 1. Assess. Run an inventory of everything running on Cloudera: tables, views, ETL jobs, scheduled workflows, Ranger policies, and who owns each one. UCX and the Lakebridge Analyzer both automate this; the output should tell you which workloads are simple lift-and-shift and which are “very complex” before you commit to a timeline. 2. Plan and pilot. Pick one bounded workload, a single business domain or a handful of pipelines, and migrate it end to end before touching anything else. This is where you decide soft migration (HMS federation, incremental) versus hard migration (full cutover of that workload's metadata and data to Unity Catalog). The pilot is also where governance redesign starts: map the Ranger policies relevant to this workload to Unity Catalog grants, and expect this to take longer than the data movement itself. 3. Migrate data and code. Move HDFS data into Delta Lake on cloud storage. Convert HiveQL/Impala SQL and ETL logic with Lakebridge Converter (or manually for anything it flags as very complex). Rebuild Oozie DAGs as Databricks Workflows. 4. Rebuild governance. Re-model Ranger/Sentry policies as Unity Catalog grants. Don't port them as-is; this is the natural point to simplify years of accumulated, overlapping policy rules rather than carry the sprawl forward. 5. Validate. Reconcile row counts, aggregates, and query outputs between the Cloudera source and the Databricks target using Lakebridge Validator or equivalent checks. Don't cut over on faith. 6. Cut over. Run the migrated workload in parallel with the Cloudera original for a defined window, then redirect consumers and decommission the Cloudera-side jobs for that workload. 7. Repeat and optimize. Take the next workload through the same cycle. Once several are live on Databricks, tune cluster sizing, enable Photon where it pays off, and move to serverless compute where the workload pattern fits. Timeline and cost: what to actually expect Treat every number below as a range to validate against your own environment, not a commitment: A pilot-to-full-migration cycle covering roughly 60 transformation jobs has been completed in under three months in documented case studies. That's a realistic floor for a well-scoped, single-domain migration, not an enterprise-wide one. Vendor-reported outcomes cite 40%+ total cost of ownership reduction and up to 30% lower storage costs post-migration, driven by the shift from always-on clusters to job-scoped compute. These are self-reported figures from migration case studies, not independently audited: useful as a directional signal, not a number to put in a client proposal without your own modeling. The governance re-mapping step (Ranger/Sentry to Unity Catalog) is consistently the most underestimated line item in migration plans. Scope it as its own workstream with its own timeline, not a subtask of data movement. Where migrations go wrong Treating Ranger policy migration as an export/import. It isn't. Budget time to redesign, not translate. Skipping the pilot. Teams that migrate everything at once lose the chance to catch SQL dialect issues, schema drift, and UDF gaps before they're expensive. Assuming Hive schema drift won't be a problem. Hive tolerates schema drift that Unity Catalog flags as a violation: column type mismatches and orphaned partitions need resolving before migration, not after. Underscoping ETL conversion complexity. Lakebridge's own complexity classification, from low to very complex, exists because a meaningful share of legacy ETL doesn't convert cleanly. Plan for manual rework on the “very complex” bucket from day one. No validation step before cutover. Reconciling source and target isn't optional insurance; it's how you catch the migration bugs that would otherwise surface in production. Is your organization ready to move? You're a good candidate for near-term migration if: Cloudera licensing, support renewal, or infrastructure costs are rising faster than your data volumes justify. Your team maintains separate tools for batch SQL (Hive), interactive SQL (Impala), and ML/analytics, and feels the integration tax. You're already running workloads in a cloud environment (AWS, Azure, or GCP) that Databricks can sit on natively. You have at least one bounded, well-understood workload that could serve as a pilot. You should slow down and scope carefully first if: Your Ranger/Sentry policy set is large, old, and undocumented: governance redesign will be the long pole regardless of how fast the data moves. You haven't inventoried what's actually running on the cluster (a surprising number of enterprises haven't). Critical workflows depend on Cloudera-specific features without a documented Databricks equivalent How Pingahla helps Pingahla is a Databricks consulting and implementation partner. For Cloudera migrations, we handle the work that sits between “we've decided to move” and a production Databricks environment: discovery and workload assessment, architecture and migration planning, ETL and SQL conversion, Unity Catalog governance design, validation, and cutover. The starting point is a migration assessment, not a proposal. We inventory your current Cloudera environment, run the complexity analysis, identify the governance work, and give you a phased plan with realistic effort ranges before you commit to the full migration. Planning a Cloudera-to-Databricks migration? Talk to our Databricks team. Frequently Asked Questions How long does a Cloudera-to-Databricks migration take? For a well-scoped single-domain migration, documented case studies show pilot-to-production cycles under three months for around 60 transformation jobs. Enterprise-wide timelines depend on workload count, ETL complexity, governance policies, and how much manual conversion is required. What happens to HDFS data when migrating to Databricks? HDFS data moves to cloud object storage such as Amazon S3, Azure Data Lake Storage, or Google Cloud Storage, typically using Delta Lake format. This separates storage from compute and enables Databricks features such as ACID transactions and time travel. Can Hive and Impala workloads be migrated to Databricks? Yes. Hive and Hive LLAP workloads generally move to Databricks SQL or Spark SQL, while Impala workloads move to Databricks SQL with Photon. HiveQL often carries over, but custom UDFs, SerDes, and complex SQL may require manual rewriting. What happens to Apache Ranger policies during migration? Ranger and Sentry policies need to be re-modeled as Unity Catalog grants. This is not a direct export/import process, so governance redesign should be treated as its own migration workstream. What tools can help migrate Cloudera to Databricks? Databricks provides tools including UCX for assessment and Unity Catalog migration, Lakebridge for analyzing and converting legacy workloads, and Hive Metastore Federation for supporting incremental migration while the legacy metastore remains available.

Talend is now part of Qlik. This walkthrough uses Talend CDC's on-premises Studio interface; core setup steps remain the same under Qlik's current release. Talend CDC (Change Data Capture) replicates and syncs data from one source to different targets in real time, without a full re-extract of the source data. Teams reach for it in situations like: Keeping a data warehouse aligned with the latest data from transactional sources. Hybrid architectures that need the cloud environment aligned with an on-premises data environment. Performance-sensitive replication that needs to run complex queries on specific columns just to detect whether a record is new, changed, or deleted. A transactional database being used as a reporting source, which drags down its performance. Maintaining an online backup. Running a distributed database. CDC can be used in different environments: on-premises, hybrid, or cloud, and it has connectors to different cloud providers such as Snowflake, AWS, or Azure, and managed services such as Kafka, AWS kinesis or Azure Eventhub. It also has connectors and support for on-premises servers such as IBM AS400, which is frequently used by financial entities and makes it unique in the market. Talend CDC Support: Databases and Capture Modes Talend CDC supports change capture on Oracle, MySQL, DB2, PostgreSQL, Sybase, MS SQL Server, Informix, Ingres, Teradata, and IBM AS/400. The AS/400 connector is the standout here: it's rare among CDC tools and matters most to teams running core financial systems on IBM iSeries. Three capture modes are available, and which one applies depends on the source database: Trigger mode is the default and works across MySQL, Oracle, DB2, PostgreSQL, Sybase, MS SQL Server, Informix, Ingres, and Teradata. It captures changes by placing triggers on the monitored tables. Redo/Archive Log mode applies to Oracle Enterprise Edition v11 and AS/400 databases. It reads directly from the database's own transaction logs instead of using triggers. XStream mode works only with Oracle v12 on OCI, using Oracle's native XStream API for lower-overhead log reads. Since Talend's acquisition by Qlik, CDC documentation and support live under Qlik's help portal alongside the legacy talend.com resources. That's the current source of truth for troubleshooting. Pingahla, as a Qlik Strategic Tier Partner with hands-on Talend CDC deployment experience, can also help diagnose configuration issues directly. How does Talend CDC work? CDC identifies the different changes that are in the source and replicates them in the target source. The replicated data comes from the different operations carried out such as: INSERT DELETE UPDATE The data sources that are producing changes can store logs with the transaction events that have been carried out on the data. These logs can be in different formats, varying according to the manufacturer. The CDC agent works by monitoring and collecting those transactional events once, to store them in its own log files (Journal), in case it’s necessary to reuse them in different replication. However, this process is oblivious to system resources and does not interact with them. In cases where we already have a database created and populated as a source, we will need to only do one full replication. From that point forward, Talend CDC will capture the changes made. It’s possible to apply scripts to the data in the source to select, transform or perform aggregations as well as apply changes to the target prior to integration. Its configuration is done in a graphical console in which we select our source and target. It operates with different roles as: Administrator Operator Viewer The replicas are created in an environment, and there will be called models; a model contains the sources and targets; Once configured, we can add additional options for these, such as scheduling the executions, changing the framework with which we integrate, or supervising the job through logs in the tool or log files. There are different frameworks with which CDC can do data replications, and each of them has additional capabilities, such as adding columns in the target, providing transformations, adding sequence identifiers, or even working with big data targets. Demo of a Standard Replication Initial Settings In this blog, I will show a standard replica, so we will select the framework as “Free”, which means that no additional columns or data will be added to what is already in the source; I will be using Talend Change Data Capture version V 7.15 .0. For this example, I have already created the source and target databases in SQL Server, which I named "training_source" and "training_target" respectively; in the source, I have a table called "students" while in the target, I have not created anything yet. Likewise, the configuration of Talend CDC towards the source and the different components necessary for the correct functioning of the tool are already installed, these are: Capture Engine Source Engine Target Engine Talend CDC Manager 32-bit ODBC connector for SQL Server in the DSN (Data Source Administrator) SQL Server Let's start: We start by configuring the source in the File -> Source subscribe menu and fill in the data according to our source configuration: Name (Alias): The name that you prefer IP address: Is the location of CDC source engine where the DB instance connection has been defined, this setup was done during the CDC installation and configuration Source type: The engine of the source DB Instance or Server name: The one configured on your server Then we notice that in the source it will show us "Training Source" with a green button that will help us to connect to it: When we connect to that source, we will see that the different configured environments where we can create the models are shown, for this example, we will use Training as our environment: Now we configure the journal, so we go to Source -> Journal Management Right click on the created DB "training_source" and choose the option “Start DB logging process” Then we can select the directory in which we want to store the journal and press Ok. Still in Journal Management, we have to select the table we want to monitor and right click on it and then, press the option “Start table logging process for”: Note: A primary key must be configured in the table to start the monitoring process on this. After starting the monitoring process on the "students" table, we need to verify that the journal is working, for this we are going to make a slight change on one of the records on this table: Note: We have changed John Doe's city to Miami instead of New York Now again in the Journal Management right click on “training_source” and “Display Journal”: We will see the only receiver available, which is the one written for the change we just made: We select it and go to the "Posts" tab and from there we will see the changes that were made: Note: The change of city is shown, the first record is "New York" and the second is "Miami" which guarantees the correct functioning of the journal. Creating the Replication: The first step is to create a configuration space within an environment; each replica within the same environment shares the same parameters and can be managed together. In the "Environment" tab, click on "Add" and fill in the fields like the following example: Environment: unique code of the environment to be created Source code: Unique code for the source, must be 3 characters exactly Environment type: For this example it’s “Training” Description: It’s recommended to add a description Click on “Add” and we will have the environment created: Note: The environment contains a tab for the source where the model is created and another tab for the target. Additionally, three tabs where the replication properties will be displayed, and graphic elements of the replica to visualize the process. Now from the “Source” tab right click on “Models” and then on “Add”: And configure the model as follows: Note: Two additional tabs “Table Options” and “Script” are shown, for which we will use the configuration set by default. Model: A unique code for the model Description: Description of the model Type: For this replication, we use JOURNAL, however, there is EXTRACT that allows a full extraction Click on “Add” and the model will be available in the “Models” folder in the “Source” tab of the “Environment”: The next step is to add Tables to the model, expanding the Model on the [+] button, then right-clicking on “Tables” and finally clicking on “Add” A window will appear to select the tables that we will add to the model: Note: As you can see, we are using the "Free" framework that doesn’t generate additional changes to our data With the "Query" button we can list all the available tables Select the tables, in this case "students" Move the selected table to the model Finish The table will appear created inside our model: The next step is to create the target, from the "Target" tab of our environment we right click on "Targets" and then "Add": The window for the new Target will open: Target: unique code for the target Description: Description of the target Target type: default value Name: Name of the instance of our target database Address: address of the server where the target database is located Exclude: it’s filled automatically as soon as we put the name of the instance Then click on “Add”, and we will see our created target: The next step is to create a distribution which means associating our model to a target, we can do it from the "Source" or "Target" tab; expand our created target or source, and click on “Distribute”: And we move the Model from the left panel to the right and click on “Ok”: A window opens automatically to finish the configuration of the distribution: Select the type of database Double-click on the connector A window will open to enter the data from our target database Click on “Ok” to add it If the connection is correct, a notification window will show us "Connection Successful" and will show us the databases available there, and finally click on "Add": We can now see from the "Map" tab that the target T01 is associated with the model M01: The next step is to create the target table, then from the "Target" tab we click on the "M01" model, then select the table to replicate, right-click on it, and finally "Create Target Table": After this we will see that a new window appears showing the DDL of the new table using the target database: Click on “Execute” and then we check in the target database to show that the table was created there, but it is empty: Run Replication: Now that the target, the model and the distribution are created, we must execute the replication; from the “Map” tab, right click on Model M01 and then click on “Properties”: From the "Recovery" tab we select the "Load" check box Then we go to the "Activity" tab, a confirmation window will ask us if we want to reload all the tables in that distribution, to which we will say "Yes". Now from the "Activity" tab click on the "Start" button After starting the replication, the fields of the "Counters" and "Last operation" section will show us the results and likewise, the distribution will remain active and waiting for any change that occurs in the source to replicate it automatically: Note: As shown, we had 3 records in the source and those same ones were selected, sent and added to the target. When the model is active, it will be green, otherwise it will be yellow, or it can be red if errors are encountered during execution: Now it must be checked in the target table to show that the records were replicated: Finally, we stop the replication by right-clicking on the model that appears in green and clicking on “Stop”. Talend CDC offers many more features for real-time replication. In the previous example, we perform a simple replication with the same source and target fields, as well as a manual execution since they can also be scheduled. In the next posts, I will show other features or functions that Talend CDC works with, as well as highlighting the differences with other frameworks available there. FAQ What is Talend CDC used for? Keeping a data warehouse aligned with live transactional sources, syncing on-premises and cloud environments in hybrid architectures, offloading reporting queries from a live transactional database, and maintaining an online or distributed backup — all without full re-extracts of the source data. Is Talend CDC real-time? Yes. It reads the source database's transaction logs (or triggers, depending on mode) continuously, so changes reach the target within seconds of the source commit rather than on a batch schedule. Which databases does Talend CDC support? Oracle, MySQL, DB2, PostgreSQL, Sybase, MS SQL Server, Informix, Ingres, Teradata, and IBM AS/400. Does Talend CDC affect source database performance? Minimally. Because it reads from transaction logs rather than querying the live tables, it avoids the load a polling-based comparison approach would create. How is Talend CDC different from Qlik Replicate or Debezium? All three do log-based change capture, but they differ in ecosystem fit: Talend CDC integrates natively with Talend/Qlik pipelines, Qlik Replicate is Qlik's broader enterprise replication platform with a wider target-system list, and Debezium is open-source and Kafka-native, better suited to teams already standardized on a Kafka streaming stack. The right choice depends on what's already in the stack, not which tool has more features on paper. Working through a CDC implementation of your own? Pingahla's team works hands-on with Qlik's Talend Data Fabric and can help scope the right data integration services for your environment. Fredy Antonio Espitia Castillo Talend Developer Certified https://www.linkedin.com/in/fredy199601/

Pingahla Accelerated Data Modernization for Snowflake, Powered by Snowflake, will enable joint customers to modernize legacy databases, data warehouses, and ETL/ELT pipelines in months instead of years New York, August 2026 - Pingahla today announced the launch of Pingahla Accelerated Data Modernization for Snowflake on the Snowflake AI Data Cloud. This new offering, Powered by Snowflake, will enable enterprises to automate the assessment, transformation, and validation of legacy databases, data warehouses, and ETL/ELT pipelines, cutting modernization timelines from years to months and landing on a governed, enterprise-proven foundation ready for analytics and AI. "Every legacy modernization effort ends at the same destination: a modern cloud platform customers can actually build on. By pairing our Modernization Accelerator with Snowflake's AI Data Cloud, we're helping enterprises clear legacy risk and land on a platform ready for the analytics and AI workloads their old environment could never support." Said Chris Evans, CRO, Pingahla. By leveraging the Snowflake AI Data Cloud, Pingahla is joining Snowflake in mobilizing the world's data to help organizations modernize legacy infrastructure without the cost and risk of a full transformation program. Pingahla's Modernization Accelerator - proprietary automation IP that complements technologies including Qlik Talend and Informatica IDMC - converts legacy ETL/ELT mappings into cloud-native SQL, Snowpark-based Python, and modern ingestion pipelines. Source data is staged in Snowflake, transformed using Streams and Tasks, and processed through Snowflake-generated SQL and Snowpark notebooks built with the help of Cortex AI, landing on dimensional models and analytics-ready presentation layers within the customer's own Snowflake environment. Many legacy modernization engagements achieve automation rates approaching 80-90%, with Pingahla's engineering and delivery team completing the remainder end to end, from assessment through migration and cutover. Partnering with Snowflake to launch Pingahla Accelerated Data Modernization for Snowflake, Pingahla enables joint customers to retire end-of-life legacy platforms, consolidate fragmented enterprise data, and reach a Snowflake foundation that's ready to run analytics and AI workloads rather than simply lifted and shifted. For example, Pingahla migrated 20-plus Oracle tables to Snowflake for outdoor products manufacturer Petmate using Informatica IDMC mappings, then built a consolidated Snowflake reporting layer for analytics and business reporting, delivered in phases over approximately four to six months and reducing Petmate's dependence on its legacy Oracle environment. Industry-leading applications are Powered by Snowflake. By building tools, applications, and solutions on Snowflake, product and engineering teams can develop, scale, and operate without operational burden, delivering differentiated products to their customers. Snowflake AI Data Cloud Product Partners help customers maximize Snowflake's flexibility, performance, and ease of use to deliver more meaningful insights. AI Data Cloud Services Partners provide industry experience, technical expertise, and strategic best practices to help customers mitigate risk and drive business value with Snowflake throughout their entire data and AI journey. About Snowflake Snowflake is the platform for the AI era, making it easy for enterprises to innovate faster and get more value from data. More than 13,300 customers around the globe, including hundreds of the world's largest companies, use Snowflake's AI Data Cloud to build, use and share data, applications, and AI. With Snowflake, data and AI are transformative for everyone. Learn more at snowflake.com (NYSE: SNOW). About Pingahla Pingahla helps enterprises accelerate the modernization of legacy data environments onto Snowflake's AI Data Cloud. Pingahla's Modernization Accelerator, proprietary automation IP that complements technologies including Qlik Talend and Informatica IDMC, speeds the assessment, transformation, and validation of legacy databases, data warehouses, and ETL/ELT pipelines, cutting modernization timelines from years to months. Pingahla holds Qlik Strategic Tier Partner status and was named Qlik New Partner of the Year, and is also an established Informatica partner. Customers, including Array Technologies and Petmate, have used Pingahla to modernize legacy data infrastructure and land on Snowflake's AI Data Cloud, ready to run, not just lifted and shifted. Media Contact: Vishal Vikram, vishal.vikram@pingahla.com

Tariff volatility, FX risk, and fragmented procurement data are breaking AI initiatives before they start. Here's what the foundation actually looks like. Every few weeks, another tariff announcement forces manufacturers, distributors, and retailers to revisit sourcing decisions they thought were settled. Whether it is new trade restrictions, FX shifts on a key currency pair, or a freight disruption in a critical lane, one thing has become clear: companies can no longer afford to wait until month-end to understand their exposure. The organizations that are managing this well are not doing it with better spreadsheets. They are doing it with a data architecture that lets them answer the right questions before the announcement, not after. And the organizations that are struggling are not struggling because they lack talent or ambition. They are struggling because their data is not connected in a way that supports real-time decisions. I see this pattern repeatedly across manufacturing, retail, and consumer goods. Leadership invests in an AI initiative, builds a pilot, and six months later the results are inconsistent, hard to explain, or impossible to act on. The AI tool is rarely the problem. The problem is not the AI. The problem is the data underneath it. AI does not eliminate data problems. It amplifies them. That observation drives everything Pingahla and Qlik built together. And it is why we think the most valuable conversation a supply chain leader can have right now is not about which AI tool to choose. It is about whether the data foundation is ready to support it. Why Supply Chain Data Is Harder Than It Looks Ask most supply chain teams to answer any of these questions in under an hour: Which products carry the most tariff exposure right now? What happens to contribution margin if tariffs on goods from a specific country increase by fifteen percent? Which suppliers represent the greatest concentration risk? Which trade lanes should we consider rerouting given current FX conditions? In most organizations, answering those questions requires a meeting, a data pull from IT, a spreadsheet reconciliation across three systems, and a finance review. By the time the answer arrives, the conditions have changed. This is not a people problem. It is a structural one. Supply chain data typically lives in at least five to eight separate systems: an ERP for orders and inventory, a TMS or freight forwarder portal for logistics, a procurement platform for supplier costs, government APIs for tariff schedules, third-party FX feeds, and supplier portals that export data in formats that do not match anything else. For organizations running SAP, Oracle Fusion, Dynamics, Infor, SAP Datasphere, Snowflake, Databricks, or Salesforce, the integration challenge compounds across each additional system. None of these systems share a common definition of a SKU, a landed cost, a contribution margin, or a trade lane. Finance is working from one set of numbers. Procurement is working from another. Supply chain operations are working from a third. And when an executive asks what the tariff exposure looks like right now, nobody can answer without running a meeting first. That is the environment in which most organizations are now trying to deploy AI. What Agentic AI Actually Needs to Work Qlik recently published a guide on operationalizing agentic AI, and the opening observation is worth sitting with: most companies are not struggling to try agentic AI. They are struggling to get real value from it. The guide identifies exactly what happens when AI runs on a poor data foundation: inconsistent data quality, lost business context, systems that strain at scale, slower performance, and rising costs. Every one of those failure modes is a supply chain problem that shows up in the market regularly. This matters because agentic AI operates differently from a dashboard or a reporting tool. It does not just surface information. It reasons across data, recommends actions, and in some configurations initiates workflows. If the data it reasons on is fragmented or untrustworthy, the decisions it supports will be fragmented and untrustworthy. You cannot patch a data architecture problem with a better AI model. The good news is that Qlik's guide makes a point worth remembering: you are probably closer than you think. You do not need to rebuild your stack. You need your systems to work together, the data, the logic, and the workflows that connect them. The Architecture in Plain Language The reason Pingahla partnered with Qlik is that solving this problem requires three things working together simultaneously, not one after the other. Luis Bernal, our Solution Architect at Pingahla, wrote earlier this year about the mathematical foundation behind supply chain optimization, arguing that trial and error lacks the rigor needed to run proactive what-if scenarios. The next step in that progression is applying trusted, integrated data as the foundation for AI-driven recommendations. You cannot skip the data architecture step and expect the AI layer to compensate. Why This Matters Right Now Tariff policy continues to shift in ways that are difficult to predict more than a few weeks in advance. FX volatility is running at levels that directly affect landed cost calculations. Supplier concentration risk, particularly for organizations with significant sourcing from a small number of countries or trade lanes, is a board-level conversation in ways it was not two years ago. The organizations managing this well share a common characteristic. They are not faster at reacting. They are set up to model scenarios before the change arrives. They can answer the question 'what happens if tariffs increase by twenty percent on goods from this country?' before the announcement, not after. That capability is not a function of better spreadsheets. It is a function of having the data architecture in place to run those scenarios in real time. Companies that are still consolidating data manually before they can even begin analysis are a full decision cycle behind organizations that have unified their data foundation. In a stable environment that gap is manageable. In the current environment it is a competitive and margin disadvantage. The organizations managing tariff volatility well share one characteristic: they model scenarios before the change arrives, not after. That capability comes from data architecture, not from spreadsheets. Five Questions Every Supply Chain Executive Should Be Able to Answer Today Here is a simple benchmark. If your organization cannot answer these questions within the same business day, without a data pull from IT or a spreadsheet reconciliation, the data architecture work is not done yet: Which suppliers represent our highest tariff exposure, and what percentage of COGS do they represent? What happens to contribution margin if tariffs increase another ten percent on our top three sourcing countries? Which products or SKUs lose margin first under current FX conditions? Which trade lanes or countries should we be evaluating as alternatives, and what is the landed cost difference? Which FX pairs represent the greatest exposure to our procurement cost structure this quarter? If those questions take days to answer today, the goal is not to answer them faster with the same process. The goal is to build the infrastructure where the answers are available on demand, and where scenario modeling runs automatically when inputs change. That is the problem Pingahla and Qlik built this solution to solve. And it is the foundation that makes everything downstream, including AI-driven recommendations and eventually autonomous procurement decisions, actually reliable. Where to Start If any of the above resonates, a few resources worth your time: Watch the webinar replay: https://www.youtube.com/watch?v=O8AAvYHbEQU&t Talk to us directly at sales@pingahla.com In 20 minutes, we will show you: Where your tariff exposure actually sits, by supplier, SKU, and trade lane Which suppliers create the most margin risk under current conditions How quickly your current architecture could support real-time scenario modeling Whether your data foundation is ready for AI-driven supply chain decisions TALK TO THE PINGAHLA TEAM — sales@pingahla.com

Every supplier and manufacturing company experiences the same challenge in one way or another: how can I buy, transport and sell my raw materials and goods from point A to point B as fast and optimal as possible? Variables such as the price of the raw materials, source, target, lane, currency exchange, and lately one of the most influential the tariffs start to stack one over the other, making it very complex to answer this question. Usually what companies do is iterate over their options based on previous experience, in other words, by trial and error. This is a method that is not inherently bad, but it lacks a strong mathematical foundation, which is necessary to explore different questions inside the business and, most important of all, to run what-if scenarios that allow the customer to be on top of future events and have a more preventive than reactive strategy. As mentioned before, a strong mathematical model allows to include all the major variables involved during the supply chain of a company and to test different configurations of the process. Questions like: what happens if I buy my raw materials from India instead of China? Or what if the Yuan experiences a sudden spike in exchange by the end of the year? Or even, what if the tariffs from China increase from 10% to 30%? We can see that not only the economic and geographical variables come into play, but also political events play a major role in the formulation of the phenomena. A very simplified but powerful version of the mathematical model looks as follows: Where is the function we want to optimize, which means finding the maximum or minimum of the function. In this case it is finding the maximum revenue of the company, but in other cases it can be finding the minimum delivery time or even the shortest route. is the weight for all the different possible factors that affect the function and is the actual variable of the function. So we can appreciate that we can basically add any type of event that can affect the revenue of the company and assign a specific weight to each of the events, so we can quantify its effect in the final outcome. This type of formulation is very common in many different areas of physics, economics and, in this case, also on supply chain modelling. With this flexible and powerful tool we can add parameters and constraints to the model and test what-if scenarios on the optimization model. For this model to work we need to have the most up-to-date data. One example is the value of the currency exchange. This is one of the most fluctuating variables but, fortunately, one with the most available data. Having a real time API that connects to the values posted by the global market allows us to have the most precise exchange data down to the minute. More challenging variables such as the tariffs are more unpredictable and can change from one day to another based on the decision of one single person. One of the strategies to keep up with the tariff variation is being alert to the news to constantly monitor any type of developments. Of course, this cannot be done manually as it would take a great amount of effort; instead, web monitoring tools can be implemented to keep up with the latest developments from trusted news web sites and transfer the updated values of the tariffs into the model. Now, if we wanted to find out what is the shortest possible route between a given list of geographical points that our raw materials need to cross before getting to their final destination, this is known as the travelling salesman problem (TSP), which is one of the simplest problems to describe but incredibly hard to solve optimally, as its total number of possibilities grows exponentially with the number of points the route needs to include. No exact solution exists for this problem, but many different algorithms offer approximations and heuristics like Nearest Neighbor, Dynamic Programming, Lin-Kernighan heuristic, etc. Next, all of this formulation of the problem is worthless if there is no way to communicate it to the actual analysts and stakeholders of the company. That’s why having an Alerts and Exceptions section in a BI visualization platform is key to inform events such as "supplier late >2 shipments this month" or "Random inspection rate increase, clearance +0.3 days", to keep the relevant people inside the company informed and to understand why specific configurations of the supply chain are selected over others. One of the best visualizations to appreciate most of the supply chain process is the following sankey chart: The nodes represent the different suppliers, country of origin, materials, destination region and product family, while the thickness of the lines that connect each of the nodes represents the revenue. In conclusion, we can see that the supply chain optimization problem is a complex challenge that involves many different variables, from raw materials and currency exchange to tariffs and political events. Instead of relying on trial and error, what companies can do is build a mathematical model based on weighted variables, which allows them to quantify the effect of each factor and run what-if scenarios so the business can be on top of future events instead of just reacting to them. Of course, the model is only as good as the data behind it, and that’s why having real time FX feeds and web monitoring tools for tariffs is so important to keep the values up to date. On top of this, algorithms like the ones used for the travelling salesman problem help to find good approximations for routing problems that are too complex to solve exactly. Finally, all of this work is worthless if there is no way to communicate the results to the actual stakeholders of the company, and that’s where BI alerts, exceptions and visualizations like the sankey chart come into play to keep the relevant people informed and to understand why specific configurations are selected over others. With this approach companies can stop reacting and start anticipating, which is the real competitive advantage in a global market where tariffs, currencies and political events can change from one day to another. Talk to Pingahla's supply chain analytics team. We'll show you exactly where your tariff, FX, and sourcing exposure sits and what it's costing you per quarter (fill the form at the bottom of the page) Or feel free to send a custom message to info@pingahla.com.

Introduction Applications created and built to use cloud computing platforms are known as “cloud-native” applications. Cloud-native testing is a specialized approach to software testing that focuses on applications and services designed for cloud-native architectures. It includes testing of microservices, orchestration tools, and other cloud-specific components. Cloud-native testing includes various types of testing, such as unit, integration, security, performance, and scalability. It plays a crucial role in phases of the software development lifecycle.   Differences between Traditional Testing and Cloud-Native Testing Environment : Traditional testing often occurs in controlled, static environments, while cloud-native testing is designed for dynamic and scalable cloud environments.   Scope : While traditional testing usually concentrates on large systems, cloud-native testing uses orchestration tools and microservices.   Automation : Cloud-native testing heavily relies on automation to test frequently changing cloud-native components, whereas traditional testing may involve more manual processes.   Scalability : Cloud-native testing involves testing for scalability and resilience in response to fluctuating workloads. Traditional testing does not address this feature.   Tools : Cloud-native testing often requires specialized tools designed for the cloud-native ecosystem, whereas traditional testing uses more traditional testing terminologies.   Security : Security testing in cloud-native applications must address data container vulnerabilities and cloud-specific security concerns, which are less important in traditional testing.   Dynamic Nature : Cloud-native testing must adapt to the dynamic nature of microservices and orchestration, while traditional testing deals with more static application structures.   Objectives of Cloud-Native Testing The primary goals and objectives of cloud-native testing include -   Reliability : Ensure the reliability and stability of cloud-native applications, especially in dynamic and distributed environments.   Performance : Verify that applications can handle varying workloads efficiently and without decrement in performance.   Security : Identify vulnerabilities and security weaknesses specific to cloud-native components, including data containers and microservices.   Scalability : Testing the application's ability to scale up or down to meet changing demands effectively.   Compatibility : Ensure our cloud-native application works seamlessly across various cloud providers and platforms.   Continuous Feedback : Provide ongoing feedback to developers and operations teams to improve the application continuously.   Compliance : Validate that the application complies with industry standards and regulations, especially when handling sensitive data.   Cost Efficiency : Ensure that the application's resource utilization is optimized over time to minimize cloud infrastructure costs and IPU consumption.   Automation : Implement automated testing processes to keep pace with frequent code changes and deployments in a cloud-native environment.   Key Advantages Of Cloud-Native Applications Agility : Cloud-native applications make rapid development, deployment, and iteration possible. With the help of infrastructure, developers can easily bundle and deliver new features or bug fixes. Businesses may react to market changes more quickly, publish updates more frequently, and gain a competitive advantage.   Cost-effectiveness: Cloud-native applications maximize resource use by scaling up or down in response to real demand. Thanks to elastic scaling, organizations can distribute resources as needed, avoiding the needless costs associated with over-provisioning. Additionally, cloud-native architectures lessen the need for expenditures in on-premises infrastructure by utilizing cloud provider services.   Better management : Testing cloud-native applications also helps to simplify infrastructure management, which is an additional advantage. Serverless platforms such as AWS and Azure have eliminated the need for businesses to worry about things like allocating storage, establishing networking, or provisioning cloud instances.   Collaboration and Communication : Cloud-native testing promotes teamwork and communication among development, testing, and operations teams. Effective communication channels and collaborative tools aid in the timely sharing of test plans and results and the resolution of concerns.   Automation and Continuous Testing : Test automation and continuous testing are the main focus of cloud-native testing. Because automated tests can be run quickly and often, every change can be completely tested before being pushed to production. Cloud-native applications are designed to withstand failures. Owing to its distributed architecture, the application can function even in the event of a failure in one of its services, providing a higher degree of fault tolerance and lessening the effect of failures on the system as a whole.   Scalability : Scalability is a huge advantage of testing cloud-native applications. Cloud-native applications are designed to scale with ease. Applications can dynamically distribute resources based on demand by leveraging containerization and orchestration platforms. This allows programs to function at their best by efficiently handling different workloads.   Flexibility and Portability : Cloud-native applications are platform-independent. They can be implemented on a variety of cloud providers or even on-premises. Because of this flexibility, businesses can choose the cloud provider that best meets their requirements and even switch providers as needed. Cloud-native applications are now exploding in the tech industry. Considering its vast benefits, most enterprises are moving towards the cloud as fast as possible.   Common Challenges in Cloud-Native Testing Testing Serverless Functions: It might be difficult to precisely estimate and evaluate response times for serverless functions because they sometimes have varied cold start periods. Since the local environment frequently varies greatly from the cloud, testing serverless functions locally can be challenging.   Handling Stateless programs: Testing becomes more difficult because stateless programs rely on other databases or services for data storage. Testers must consider the application's statelessness to ensure that each request may be handled separately.   Complex Interactions Among Microservices: When there is asynchronous communication, it can be difficult to coordinate testing across several microservices. It might also be difficult to confirm that microservices operate in a union since modifications made to one service may impact others.   Diverse Cloud Environments: Vendor Lock-In—Because every cloud provider offers different features and services, it might be challenging to guarantee cross-platform compatibility. Service Dependencies—Testing can become challenging when an application uses third-party APIs or various cloud services.   Best Practices for Efficacious Cloud-Native Testing Shift Left : Perform testing as soon as possible during the development phase to identify problems early and lower the cost of addressing them later.   Leverage Automation : Invest in automated testing to stay up with rapid deployments and changes in cloud-native settings. Make consistent use of infrastructure as code while establishing test environments.   Chaos Engineering : Utilize chaos engineering to find weak points in your system and ensure it can fail gracefully. To continuously increase system resilience, conduct chaos experiments regularly.   Monitor and Observe : To acquire knowledge about the performance and behavior of applications and implement strong monitoring and observability procedures.

Imagine you would like to do an analysis for your current job or business. For this analysis you would like to use graphs, tables, maps and add a layer of interactivity so the users can obtain different insights from your visualizations and obtain valuable information from the business that will help you take informed decisions in the future. Now, the question arises: which business intelligence (BI) visualization tool should I use? Tableau or Dash Plotly? This article will try to attempt to help you answer this question and which visualization tool is more suitable for you. I am a Sr. Data Engineer for the data integration consultant company Pingahla. Throughout my career, I’ve helped companies to ingest, process and present their data in such a way that helps managers and stakeholders take informed decisions in their businesses. I’ve used Tableau and Dash Plotly to present these results in more than 10 different projects. Additionally, I possess the Tableau Desktop Specialist Certification and the Tableau Certified Associate Consultant Certification. I have my fair share of experience using both tools and I will share to you what are the benefits and downsides of using each of them. Nevertheless, this is just my opinion so take with a grain of salt what I am about to present to you. The main difference between using Tableau and Dash Plotly is its complexity. Tableau is designed in such a way that the “drag and drop” mechanic plays a huge role while creating visualizations. For example, if you want a sales over time analysis you just drag the time in the column shelve, the sales in the rows shelf and there you have it, a visualization made in less than thirty seconds. You can also select easily what type of graph you would like to use and format it in the style you want. With Dash Plotly things are not so simple. As these types of visualizations are constructed using the libraries Dash and Plotly from Python, all the frontend and backend of the dashboards are made by writing Python code, that could be a big condition for many people who do not know yet how to program. As discussed before, speed is also a factor to consider. In Tableau, complex visualization and dashboards may be created in a matter of seconds if you have a clear idea on what you want to create as many of the functionalities are intuitive. This means that if you don’t know exactly how to make something, you can experiment and look around the window and will probably find the answer quite quickly. In Dash Plotly the story is different. You need to keep writing and testing your code to check its functionality frequently (as with any piece of code). This process is prone to make mistakes easily as just one wrong character can damage your visualization. Patience and attention to detail are key skills that are needed for programming and especially if you are making dashboards. Trouble shooting can also be a challenging task in which seamlessly unimportant things such as indentation of the code can make the difference on running the code successfully or crashing it. If you would like to learn more on how to use the Dash Plotly framework, there is a huge community surrounding Python scripting and specifically for Dash Plotly in Youtube that is the Charming Data channel from Adam Schoreder. Nevertheless, the process is undoubtably slower than it would be in Tableau. Another factor to consider is the interactivity that Tableau can offer on its dashboards. Suppose you have a dashboard that presents the sales of different products in the USA. The dashboard has a map of the USA on the top and at the bottom is presented the number of sales by product. Imagine you would like to know the number of sales from just one city and not the entire country, normally you would do this using a filter in which you pick a city from a list. However, Tableau offers the option of selecting one city on the map and automatically affects the amount of sales graph by filtering it by the selected city. This process is called a dashboard action, and there are several of them in which you can alter the results of one or several graphs depending on an action made on the target graph. This offers an interesting layer of interactivity that the user can work with to obtain more specific insights during the analysis. Unfortunately, Dash Plotly does not offer this kind of options and different graphs in a dashboard cannot be affected be the action of another graph. For any data analysis project, it is necessary to do some kind of data processing whether it is light or heavy. In Tableau Desktop and Tableau Public it is possible to make light data processing using table calculations which are several functions that ranges from string and numerical up to date and aggregate functions. These functions, normally, are simple to use and each one of them contain a small description and example to help the user on how to choose them properly. Level of Detail (LOD) calculations are also offered, which are calculations that do not depend on the level of granularity of the view and are executed before dimension filters, measure filters and table calculations (this is one of the most complex topics in Tableau so don’t worry if it doesn’t make a lot of sense to you). If a heavier data processing wanted to be achieved using Tableau, there is a specific product named Tableau Prep Builder is a tool design to make preparing data easy and intuitive to combine, shape and clean data for analysis in Tableau. In the case if Dash Plotly, as it is written in Python code there exists a huge number of data processing libraries that can help you do any kind of light or heavy data transformations, like Pandas, Polars and Numpy to name a few. In this aspect Dash Plotly is much more flexible and allows a wide range of possibilities that offers the suits the user for a given situation. When a dashboard is finally created and you would like to share your findings with the world, with Tableau you can accomplish this by using Tableau Cloud, Tableau Server, Tableau Online or Tableau Reader depending on your specific needs. With Tableau Server you can assign different roles to your colleagues which define what actions they can implement on the dashboards, ranging from Viewer, Explorer and Creator. With Tableau Online, you don’t need to worry about scaling, as Tableau is in charge of handling these kinds of features so that you don’t have to. With Dash Plotly, as the whole dashboard is written in Python code, it is sufficient to find any kind of script host server that can run the code. There are many alternatives, in the past Heroku was very famous as it offered a free tier for developers. Unfortunately, that is no longer the case. Now, Render is a great alternative to host dashboards design using Dash Plotly as it is free to use. Nevertheless, if heavier computation power is needed or scaling up is also a need, the free tier will not be sufficient and better capabilities should be investigated for payment tiers. You can also deploy your Dash Plotly applications using AWS and if you don’t know how to in Pingala’s YouTube channel there is a video detailing how to do it step by step. Now regarding the cost of using each BI tool; Tableau is known for being an elevated cost program with subscriptions ranging from $12-$70 USD per user. Tableau Public is a free version of the software in which you can learn almost 90% of the capabilities of the paid version (great for anyone who is planning to learn how to build dashboards with Tableau). But for connecting to databases and sharing the dashboards to the community, a paid version of Tableau is required. One of the main advantages of the Dash Plotly framework is that is completely free. You can download Python, any Python IDE like Visual Studio and PyCharm, download the required libraries and start creating your own dashboards. As mentioned before, the deployment is also free if you do not require big computational power. Another advantage of using Dash Plotly is that, as mentioned before, there is a limitless number of libraries that can be used from machine learning process up to web scrapping to the internet, giving a huge potential to the dashboards by being fed by any type of information or algorithm a trait that is not available in Tableau. Tableau does have extensions or plugins that allow to increase the capabilities of the program but is not near to what Python libraries have to offer. In conclusion, if you are looking for a fast solution to build a dashboard that is not hard to use and are willing to pay a good amount of money to use the product, Tableau could be a good option for good. If you are looking for a much robust solution that may need special capabilities only offer on specific libraries, you already now how to program and prefer a free to use solution, then Dash Plotly is the better option for you.

The Pingahla Informatica MDM team has been on an incredible journey helping customers implement and scale their Informatica MDM environments. Over the past few months, we’ve been working on something we’re really excited about - an accelerator designed to make duplicate detection in Informatica Cloud MDM more flexible and easier to integrate into modern applications. Today, we’re introducing Pingahla’s Informatica MDM Duplicate Shield . This new accelerator acts as a microservice for duplicate detection and validation , built specifically for organizations using Informatica Cloud MDM. It allows teams to leverage Informatica’s powerful matching engine while maintaining full control over their own user interface and workflows. What Is Pingahla’s Duplicate Shield? Pingahla Duplicate Shield enables organizations to access Informatica’s deduplication capabilities through APIs rather than being limited to the standard out-of-the-box UI. This means teams can integrate duplicate detection directly into their own applications, portals, or customer workflows. With Duplicate Shield, you can: Connect to Informatica’s powerful deduplication engine through APIs Run real-time or batch duplicate checks Display suspected duplicates inside your own branded frontend Match records across multiple brands or customer touchpoints Seamlessly integrate with Informatica MDM SaaS A Simple Example Imagine a customer signing up for a loyalty program on your website. Instead of using Informatica’s default UI, you can integrate Duplicate Shield directly into your sign-up form . The service will call the Informatica backend, check for existing records using IDMC and MDM, and instantly flag potential duplicates. Even better, the results can be displayed within your own portal interface , maintaining your brand’s look and feel. Why We Built It Many customers love Informatica’s backend capabilities—especially its advanced matching engine and scalability . However, we repeatedly heard the same request: “Can we keep the power of Informatica’s matching engine but use our own UI?” Organizations often want: Custom sign-up flows Embedded duplicate checks inside CRM or applications Interfaces that match their brand identity Unfortunately, the default Informatica UI has limited customization options . So instead of waiting for a solution, we built one. Pingahla Duplicate Shield delivers: The intelligence of Informatica MDM and IDMC The flexibility to build your own front-end experience What’s Next? Pingahla Duplicate Shield is currently in the final stages of QA and packaging, and we’re preparing for general availability . We’ve already been testing it with select customers, and the feedback has been extremely positive - especially from teams that need more control over how MDM functionality appears within their applications. If you are: Working with Informatica Cloud MDM Looking for greater UI flexibility Struggling with white-label limitations We’d love to connect. Reach out to the info.pingahla.com  to learn how Duplicate Shield can help extend your Informatica MDM implementation.

The India AI Impact Summit 2026 made one thing crystal clear. AI's explosive potential in 2026 depends less on flashy algorithms and more on data maturity. Poor data quality, silos, governance gaps, or unreliable pipelines can derail even the most advanced generative AI, predictive models, or agentic systems. As organizations race to adopt AI for economic growth, operational resilience, and innovation, the real differentiator is a rock-solid data foundation. That is exactly where Pingahla shines. As a boutique data management and cloud analytics firm, we do not just support AI; we enable it. We enable it to deliver real and trustworthy impact. Founded by passionate data experts with the core belief of "Excellence in Everything We Do," Pingahla helps organizations transition to a truly data-driven future. What Pingahla Brings to the AI Table Pingahla partners with the world's leading platforms, such as Amazon Web Services, Microsoft Azure, Informatica, Talend, now part of Qlik, Databricks, and Snowflake, to deliver: Seamless data integration and delivery Moving beyond legacy ETL to modern ELT pipelines that feed AI workloads efficiently. Cloud-based analytics solutions Scalable environments for real-time insights, dashboards, and advanced analytics that power AI decision-making. End-to-end data pipelines and quality management Including our proprietary Pingahla Data Quality Accelerator (PDQA), infused with AI capabilities to clean, reconcile, and enrich data. This reduces bias, hallucinations, and errors in downstream AI models. Strategic consulting to turn raw data into actionable insights From data strategy assessments to governance frameworks that ensure compliance, security, and trust. We operate across on-premise, cloud, and hybrid setups, optimizing ROI on technology investments while enabling secure and governed data access. Our recent recognitions, such as being named Qlik's New Partner of the Year, and solutions like the AI-enhanced PDQA on Databricks, demonstrate how we inject quality and intelligence directly into data flows. In 2026, AI is not just about algorithms. It is about data maturity. The summit repeatedly emphasized that poor data quality, silos, or governance issues derail even the most advanced AI projects. This is where Pingahla fits perfectly. We bridge the gap between ambitious AI visions and practical, reliable execution. Why Data Foundations Are Critical for AI in 2026 The summit's key takeaways align directly with our expertise. Data Quality and Governance as AI Enablers AI models thrive on clean, consistent, and compliant data. Our tools, such as Talend Data Quality Accelerator, Informatica, and the Pingahla PDQA, ensure enterprises trust their inputs while minimizing bias and failures in AI outputs. As highlighted in our recent webinar on tariff, FX, and supply chain risk management with Qlik and Pingahla, AI-powered data reconciliation delivers what-if scenarios and analytics that drive resilient decisions. Cloud-First AI Scaling Partners like AWS, Azure, Databricks, a leader in AI and ML workloads, and Snowflake enable us to build scalable and secure cloud environments. This supports generative AI training, real-time inference, and lakehouse architectures without on-premise limitations. We are helping clients migrate from legacy systems such as Cloudera to Databricks to accelerate AI initiatives. Responsible and Inclusive AI The summit's emphasis on ethics and accessibility mirrors our approach. We prioritize compliance, security across hybrid, on-prem, and cloud environments, data lineage, and democratized access, ensuring AI benefits businesses of all sizes across India's growing ecosystem. Real-World Impact Through Analytics Our cloud analytics power the decision layer that AI augments. This includes predictive insights, demand forecasting, operational optimization, risk detection, and process automation. Clients already use our pipelines to feed machine learning models across industries such as manufacturing, healthcare, CPG, and luxury goods. Pingahla's Fit in India's AI Journey India is emerging as a global AI leader, and the Delhi summit underscored the urgent need for robust data ecosystems. With our Pune office powering Indian operations, alongside our presence in New York, Canada, and Colombia, Pingahla is uniquely positioned to help both local and international clients: Accelerate AI adoption by modernizing data infrastructure Reduce time to value for AI projects through proven integration frameworks such as point-and-click ETL and ELT, and secure data enclaves Build resilient and compliant systems that support long-term AI innovation Whether enabling real-time dashboards for leaders, ensuring data lineage for regulations, or powering cloud migrations for AI workloads, our services make AI practical, impactful, and trustworthy. If you are exploring AI but facing data readiness challenges such as silos, quality issues, governance gaps, or scaling concerns, let us connect. Pingahla is here to turn your data into the high-octane fuel that powers meaningful AI impact. What data challenges are you facing in your AI journey? Share in the comments. I would love to discuss.