#on-prem

[himanithewriter]

Legacy Modernization: How Hexaview Migrates BFSI Clients From Mainframe/On-Prem Systems to Salesforce 

In today’s fast-moving financial sector, outdated legacy systems can slow operations, complicate compliance, and frustrate both employees and clients. Advisors waiting on slow reports, claims stuck in backlogs, or bankers juggling multiple disconnected systems are all too common scenarios. For BFSI (Banking, Financial Services, and Insurance) organizations, legacy modernization is no longer just a technical upgrade—it’s a strategic necessity. Hexaview helps clients transition seamlessly from mainframes and on-premises systems to Salesforce cloud platforms, delivering speed, efficiency, and measurable business value. 

Hexaview’s Structured Approach to Modernization 

Modernizing legacy systems can feel complex, but Hexaview turns it into a smooth, end-to-end process: 

Application Re-engineering: Legacy applications are refactored or rebuilt using cloud-native Salesforce frameworks, creating scalable and maintainable solutions. 

Data Modernization: Critical data from mainframes (VSAM, IMS) or on-prem databases is migrated into unified, query-optimized models on Salesforce, enabling faster reporting and actionable insights. 

Infrastructure Migration: Workloads move to secure, high-performance Salesforce cloud environments, with rollback options to minimize disruption. 

UI/UX Transformation: Outdated interfaces are upgraded to Salesforce Lightning, offering intuitive, responsive, and interactive user experiences. 

Post-Migration Support: Continuous monitoring, performance optimization, and BFSI regulatory compliance checks ensure systems remain efficient and secure. 

Industry-Focused Modernization 

Hexaview tailors its modernization strategies to meet the specific needs of BFSI sectors: 

Banking: Core banking and reporting systems are modernized without downtime, fully complying with KYC, AML, and FINRA regulations. 

Insurance: Policy and claims platforms are migrated to scalable Salesforce architectures, enabling faster claims processing and streamlined regulatory reporting. 

Wealth Management: Advisor dashboards and client tools leverage Salesforce AI and analytics, offering richer insights and more personalized client experiences. 

Case Study: Salesforce Classic to Lightning 

A wealth management firm struggled with a heavily customized Salesforce Classic environment. Hexaview applied a “Discover, Roll Out, Optimize” strategy: 

Visualforce pages were converted into modern Lightning Components. 

Custom Aura Components enhanced interactivity and usability. 

The firm achieved a 50% boost in operational efficiency, simplified workflows, and interactive dashboards that enabled faster, informed decision-making. 

Key Benefits of Legacy Modernization 

Partnering with Hexaview for Salesforce legacy migration delivers tangible outcomes: 

Faster Time-to-Value: Reduced manual effort and smoother operations. 

Unified Customer Data: Consolidated data provides a single view of clients, supporting faster decisions and stronger compliance. 

Future-Proofed Salesforce Investments: Scalable and secure architectures support automation, AI-driven insights, and long-term growth. 

By transforming legacy systems into cloud-enabled Salesforce platforms, Hexaview empowers BFSI organizations to work smarter, stay compliant, and deliver superior experiences to clients. Legacy modernization is no longer a challenge—it’s the gateway to operational excellence and business innovation. 

[abihasna]

If you’re looking for on-premise chat solutions for your business applications, several options are available in this article.

[unscramblegk]

Thank you for 10 years

Today marks the company’s 10 year anniversary.

It’s amazing that we’ve managed to stay in business this long, and I'm thankful to all our customers, suppliers, contractors, and interns for making it possible.

This post will also serve as the last one for Unscramble. The company name has changed to On-Prem, and an EOL has been set for the On-Prem Meta appliance and service.

The company will remain in business, but we’re shifting our focus to other things.

We’re excited for the future, and look forward to another decade of awesomeness.

Thanks!!

[unscramblegk]

Announcing Cloud-Init for On-Prem appliances

Today we're announcing the official release of cloud-init deployed on our On-Prem virtual appliances.

The entire setup is fully Open Source under the permissive MIT license, and can be used/tweaked by anyone as they see fit.

Cloud-init on-premises

For those unfamiliar with cloud-init, it's a tool installed on the appliance which allows it to be configured with certain settings on boot. The settings are not pre-baked into the VM, but rather fetched from the VM's host (ex: EC2, VMware, Proxmox, MaaS, etc). They can be obtained in the form of a removable drive (ex: /dev/sr0), or from a "Metadata URL" such as http://169.254.169.254/.

Pre-configured settings are fine for defaults, but there has always been a need to provide additional settings such as NTP, network, DNS, storage, apitoken, before the VM is first booted. That's where cloud-init comes in. It allows a true zero-touch deployment of On-Prem appliances on various on-prem AND cloud providers.

Unfortunately with TinyCore Linux and an immutable OS, that "feature" has always been impossible to implement, until now.

The changes we've implemented for cloud-init to work on our appliances only add a few MB (~3.8MiB) to the size of the appliance, and require an ugrade from Python v2.7 to Python v3.

How it works

We add a system overlay into the TinyCore Linux rootfs, along with 3 new extensions (and their dependencies) which are loaded on boot:

ifupdown.tcz

cloud-init.tcz

cloud-init-deps.tcz

The /opt/bootsync.sh will run cloud-init and then try to setup networking through /opt/network.sh, which is simply calling cloud-init once more with different arguments. The reason for this is to provide backward compatibility for existing On-Prem TinyCore deployments.

Note: If there is no usage of the network.tcz, jidoteki-admin.tcz, or jidoteki-admin-api.tcz extensions, /opt/network.sh can be removed from /opt/bootsync.sh and replaced with:

/usr/local/bin/cloud-init modules --mode config

Each step in the cloud-init runs can be found in /etc/cloud/cloud.cfg.

The config modules are bootcmd which are the actual Shell scripts found in /etc/cloud/scripts.

Customizations can and should be added to custom.sh and custom-once.sh. If it's not immediately obvious, the once.sh and custom-once.sh scripts will only run once per boot. Unlike typical cloud-init installations, the once scripts will run again on reboot (because the OS is immutable).

Userdata, Metadata, Vendordata

The Shell scripts provided for this cloud-init deployment will read settings from various files on the system, including any userdata or vendordata provided to the system.

The order of precendence for reading configuration values are:

backed up files from /opt/.filetool.lst

userdata from /var/lib/cloud/instance/user-data.txt

vendordata from /var/lib/cloud/seed/nocloud-net/vendor-data

Note: Metadata is only currently used by cloud-init to configure SSH public-keys. All other metadata is ignored, but still accessible to applications running on the TinyCore Linux appliance.

Userdata

Tested with EC2, Proxmox, and NoCloud, the userdata will be discovered by cloud-init and read directly from /var/lib/cloud/instance/user-data.txt. From testing, it appears cloud-init handles Base64 decoding of userdata automatically provided by EC2.

Note: Userdata is not parsed by cloud-init, but rather read manually by various Shell scripts. This means it is not possible for userdata to overwrite values from /etc/cloud/cloud.cfg, and it is not possible to provide userdata which contains a shell script or other malicious features. Userdata should only contain key: value pairs.

Vendordata

The vendor-data is added to the /var/lib/cloud/seed/nocloud-net/ directory on the rootfs. It is also possible to add a network-config (v1 config) to that directory for pre-configuring the network.

Note: Similar to userdata, the vendor-data is not parsed by cloud-init and should only contain key: value pairs (except for network-config, which is parsed by cloud-init's net-convert tool).

More info

For more information, please see the README.md from our Open Soure repository.

Moving forward

We're hoping to add cloud-init to all our customer appliances in the coming month, so all their customers can benefit from the advantages cloud-init provides.

As usual, feel free to contact us and let us know your requirements. We'll be more than happy to help modernize existing apps by deploying them as part of a well-designed on-premises virtual appliance (OVA).

[unscramblegk]

Meta OVA release v13 (1.13)

At the end of November 2019, we quietly released v1.13 of our On-Prem Meta appliance.

This release contains a few security fixes, minor bug fixes, and a major OS upgrade from TinyCore 7.x to 10.x.

Some notable changes below:

Improved token setup

One feature which we quickly implemented in the Jidoteki Admin API was the ability to configure the initial API token on first-use. Unfortunately this has some important security implications for those deploying an OVA in a hostile network (or on a public network).

To fix this, we've enabled the ability to optionally enable our "first-run" feature (disabled by default). This generates a random passphrase as an API token when the OVA is first launched. The random passphrase can only be seen from the console (ex: by an infrastructure admin), or programmatically by an app running on the OVA appliance.

This initial passphrase must then be used to reset the API token and complete the "first-run" process.

Broken GitHub integration

Our GitHub integration was broken since the day we launched it. Although it worked on our test appliance because we weren't testing it correctly. Oops. This is fixed, and the Meta OVA can now receive GitHub push webhook events and automatically pull the latest code changes.

New options in certain API calls

We're often adding new input/output parameters to API calls to provide more functionality for our customers without breaking existing functionality. A favourite of mine is the builddate, which is central to pretty much every API call. Certain API endpoints required you to parse the reply to determine the builddate, so for those endpoints we now return that value directly at the top level of the JSON response, to facilitate chaining API calls which depend on the builddate.

We've also added the ability to suppress the log output when polling for a build's status. The log output could easily reach a few hundred KB, and polling that much data every 5 seconds was not efficient. Now it can be disabled and the status output reduced to just a few KB instead.

Finally, for our customers building multiple flavours of the same appliance (ex: small, medium, large), it is now possible to only build the small OVA, or any combination of flavours through the ova_files parameter on the POST /builds endpoint. This is good for testing when you only need to test one OVA (since technically, the only difference between various flavours are the disk sizes). For production builds, the ova_files parameter can simply be omitted.

The future

Ths year we've begun working on Meta OVA v20 (v2.x) which is so far quite a significant improvement.

Our focus has always been to help our customers deploy Enterprise on-prem virtual appliances, so with that in mind, our next OVA will contain many more enterprise features which can also be integrated into customer appliances.

We've also recently launched a new set of Open Source tools for working with the Meta OVA, so make sure to read our next blog post for details on that.

As usual, feel free to contact us and tell us your story. We'll be happy to help you get up and running with On-Prem Meta so you can start building and deploying your own on-prem appliances.

[cakriwut]

SP2019 OnPrem - Howto enable missing new Document template

When I created my first teamsite in SharePoint 2019 on-prem, I was impressed with the new elegant design. However as soon as I opened the Document Library – I feel that something was amiss.

Following screenshot is the Document library in SharePoint 2019 on-prem:

Following screenshot is the Document library in SharePoint Online:

I can no longer find “Document” template when I click on “New

View On WordPress

[unscramblegk]

On-Prem Meta and Setup pricing changes

Since our last pricing update 1.5 years ago, we've automated most of the manual tasks in our "Setup plan". Thanks to our awesome customers, we've managed to sand down any rough edges, and build a reliable appliance for their daily appliance builds.

Our Setup process still requires some manual work, but much less than when we first started six years ago, so most of the value we provide exists in our On-Prem Meta Appliance (Meta OVA) instead.

For these reasons, we are waiving the Setup fee on the condition that new customers purchase a minimum 1 year license for the Meta OVA.

You can find more info on our pricing here.

The Meta OVA has gone a long way in just two years. It now has the ability to run on AWS and build AWS/GCP/Azure appliances in addition to the other on-prem platforms (KVM/Xen/VMware/Hyper-V), it integrates directly with GitHub, provides powerful build management tools, and contains a ton of performance optimizations to reduce memory and CPU usage - all while remaining under 60MB.

If you're looking for the perfect solution to convert your ./installer or SaaS application to run on-premises (or airgapped in "The Cloud"), feel free to contact us and we'll be happy to help.

[unscramblegk]

Meta OVA release v11

We recently released v11 of our On-Prem Meta OVA. This release contains a handful of security updates, some great new features, and a huge memory optimization.

Memory

Previously, one build would require nearly 3x the amount of RAM for the size of the build (i.e: a 350MB build would require 1GB). We've made some changes which allow us to lower that requirement between 33% and 50% less RAM for each new build. This means it's now possible to do 2x more concurrent builds, or provision a 2x smaller OVA.

Features

The biggest new feature is the official integration of GitHub webhooks. The Meta OVA can now directly accept a GitHub push event, and can automatically clone/pull the repository changes prior to making a build. This removes the need to manually push Git changes to the appliance, and opens the door for automatically launching builds when a webhook is received.

We've also added a few new API endpoints and parameters, with no breaking changes.

Security

The usual suspects, such as Nginx. OpenSSL, and Qemu, have received security updates.

Of course, we've incorporated many bug fixes implemented over the last few months, particularly in regards to race conditions with certain asynchronous tasks.

We're already preparing for our v12 release, which will include a few long-awaited and often requested features. Stay tuned for more updates.