Advantages of Nearshore Outsourcing

Leverage proximity

This was our first wave, the idea behind the concept was to fill the gap left by India-centric global service delivery. This concept remains as a solid differentiator of Colibricode, although it is just the beginning of our venture in global services.

This component of the value proposition encompasses the following:

Proximity and Time Zone

Geographic proximity and similar time-zones allowed companies to have increased face-to-face interaction, allowing more complex types of projects to be done nearshore. This filled a gap left by distant, offshore locations such as India.

Cultural Affinity and Ease of Doing Business

Because of proximity, most nearshore locations have closer cultural affinity to their primary markets than offshore locations. Mexicans for example are very familiar with U.S. lifestyles, customs and styles of communication. In addition, because of NAFTA, Mexico has not only been an important manufacturer and provider of services to the U.S., but is an important market for U.S. businesses. This business exchange has further increased familiarity between the two cultures, helping to minimize communication issues due to cultural differences. In addition, because of NAFTA, visa issues are virtually non-existent as Mexicans can obtain TN visas (renewable 1 year term) easily.

Cost Savings

Depending on the location, cost savings can be equal to that of offshore locations. For example, Mexico was able to give substantial cost savings to U.S customers that were comparable to cost savings in India because indirect costs such as contracting costs, due diligence, communication and travel were lower.

Colibricode have a justified reputation in the coding industry as established, result-oriented leaders.

Total Cost of Engagement

Total Cost of Engagement, or TCE, is an approach that evaluates the total expenditures of offshore engagements, bringing to light the cost competitiveness of a mature nearshore model, even when compared to highly cost-efficient offshore models.

Although nearshore rates tend to be higher, the overall cost of nearshore engagements is equivalent or less than offshore, because of the efficiency gains that working in close proximity to the US and in the same time zones can bring. Through the use of a mature and disciplined process, the Nearshore model is much more efficient in achieving higher percentages of work performed at a lower cost location than offshore. 

By using a strong quality model, we build the necessary infrastructure to support work remotely, which even with the benefits of a nearshore location, still represents challenges. The quality model supports our capability to have a very high nearshore leverage (work performed at the low-cost facility).


World-class cost-efficient services

Measurable and ever-evolving performance; at lowest Total Cost of Engagement possible.

Fill the gap left by India centric global sourcing.

We believe that a solution provider must find ways to make its client’s life easier, while still providing the best services available in the market. Our clients need specific customized solutions and the quality services of a high-performance provider.

That is why we created the Global Nearshore Model, as a way to fill the gap left by India-centric global delivery models. By leveraging Colibricode’s capabilities, corporations can reap the benefits of global sourcing, while fulfilling their needs for high interactivity, on-demand communication, rapid response to change, risk diversification, reduced attrition, and multi-language support; critical elements that are not adequately addressed by an India-exclusive model.

Outstanding customer experience

Business value is measured by price, quality, and timeliness of the deliverables. Experiential value, on the other hand, is focused on addressing the needs, wants, and concerns of the people – individuals – interacting with the provider. Both elements play a key role in the success of global sourcing.


Reduce the complexity

  • Consolidate the portfolio of new and legacy applications into a single team.
  • Ensure that vital applications behavior is predictable and its operation remains uninterrupted
  • Reduce the multiplicity of vendors and leverage the strengths of a robust yet flexible partner with global reach
  • Monitor Service Level Agreements, not timesheets


  • Increase the ability to compete globally with a global partner
  • Operate under world-class standards, regardless of the local, regional or global nature of your needs.
  • Locate the service wherever in the world it makes the most sense for your business, not your vendor’s.
  • Take advantage of “global nearness”. Manage day-time operations always during the day, regardless of where in the world they are.
  • Improve response time to customer’s needs by having your support team always near.

Optimize costs

  • Reduce the Total Cost of Engagement. Lower indirect costs. Leverage the lowest cost location to its fullest.
  • Optimize processes. Consolidate functions. Reduce defects. Ever evolve the Service Level Agreements.
  • Allow people to reach their highest potential. The right task at the right location.
  • Optimize the use of technology. Accelerate new technology deployment while ensuring its effectiveness.

Support the evolution of the business

  • Support globalization initiatives
  • Expedite the implementation, customization, and deployment of enterprise applications at the best possible ROI.
  • Build a platform for the future. Implement solid applications and the processes to support them.
  • Maximize business knowledge. Assign resources to business valuable tasks. Extract business logic embedded in legacy applications.

Making a Point for Component-Driven Development

The Problem with Traditional Approaches

The traditional workflow to create web applications using a framework like Drupal is to start with site building and back-end work, then implement the theme on a markup. This workflow is not as simple and clean as it could be, which complicates the front-end work and maintenance.

This approach makes it difficult for back-end and front-end teams to work in parallel from the start, since front-end developers must wait for the feature to be built before drilling down into the sea of divs to target the right elements often with custom selectors, making it difficult to keep it DRY. Styles are not isolated, so the risk of some overriding others is high and continues to get more complicated over time. This is even more likely if the team doesn’t carefully follow a methodology like BEM (Block, Element, Modifier).

Another difficulty with this approach is that project managers, clients, and QA members are forced to wait until the project is getting very close to completion to start their reviews. Such a delay puts unnecessary stress on every member of the team and the client.

The Solution: Component-Driven Development

Component-driven development helps solve these problems, allowing every part of a web application to be defined and designed independently. Therefore, teams are generating a style guide from the very beginning.
Components can be as simple as a button and can be grouped to create more complicated structures. All the markup, styles, and JavaScript required by the component are encapsulated, avoiding the risk of accidentally modifying other elements and eliminating the need for extra selectors. Components can be defined once, then reused and tested on the browser for responsiveness from the beginning without waiting for the backend to be ready.

Additionally, this approach provides a good experience for back-end developers. They know exactly what markup structure is needed to generate to bring each component to life, and they can immediately view modifications made to features.

Using components simplifies the task of creating a sustainable technical architecture. Maintenance of the project can be much simpler with this approach due to a library of independent elements with its own HTML, CSS, and JavaScript that allows for a reusable and efficient code. Further, this accelerates development which allows testing to start earlier in the build and ensures a consistent experience.

A component-driven development approach is becoming more recognized as a best practice among development teams. On the client side, clients will love to see and interact with a living style guide early in the initiative that can be consistently modified and improved. Implementing a component-driven development workflow can bring significant improvements to all aspects of your development lifecycle.

Migrations in Drupal 8: Unleashing the Basics

In this post, we will discuss the base knowledge needed to understand how migration works in Drupal 8.

Migrations in Drupal 8 follows the ETL process which stands for Extract, Transform and Load.

For the Drupal migration process, the Extract phase is called “source” and is handled by source plugins. The Transform phase is called “process”, handled by process plugins, and the Load phase is called “destination” handled by destination plugins.

The Migrate core module provides an API for migrating configuration and content to Drupal 8.

Source plugins

The first step is to extract data from a source and return it as a set of rows. The source is typically a Drupal 6 or 7 database, but it can also be a CSV, JSON, or XML file.

Each core module implements their own source plugins that can be used to migrate content or configurations from Drupal 6 or Drupal 7 sites. For example. the source plugins for User module can be found at

[sourcecode language=”plain”]core/modules/user/src/Plugin/migrate/source/

You can also create your own custom source plugins to extend core source plugins in your custom modules.

Process plugins

Each row of data provided by source plugins can be passed through one or more process plugins, which operate on the source data to transform it into the desired format.

A list of core process plugins can be found here.

Process plugins for User core module can be found at

[sourcecode language=”plain”]core/modules/user/src/Plugin/migrate/process/

Destination plugins

Destination plugins are responsible for saving new data as Drupal content (node, user, taxonomy, etc.) or configuration (content types, fields).

Destination plugins for User core module can be found at

[sourcecode language=”plain”]core/modules/user/src/Plugin/migrate/destination/

Migration plugins

Migration plugin definitions are stored in a module’s ‘migrations’ or ‘migration_templates’ (for backward compatibility) directory. Examples of migration plugin definitions can be found at

[sourcecode language=”plain”]core/modules/user/migrations


In your custom module, most of the migration magic takes place in config/install/migrate_plus.* YML files where you can define Migration ID, source, process, destination, and migration_dependencies.

Useful contrib modules for migrations: